Agile delivery in ServiceNow: running CWM sprints, choosing CWM or Azure DevOps, and connecting LeanIX

The short version

1. CWM can run sprints as well as Jira does, but only once deployment stops defining “done”. Count development at Dev Done, and acceptance and deployment as separate numbers. If your Definition of Done includes UAT, only accepted points are velocity.
2. Keep the story ↔ update set and story ↔ change links for traceability. Just don’t make a story wait for its change before it can close, and split stories by the solution, not by the calendar.
3. A story waiting in UAT shouldn’t fill next sprint’s capacity. Close each sprint on time, move unfinished work to the backlog, re-estimate what’s really left, and manage UAT as its own queue.³⁴
4. CWM now has native velocity, burndown and burnup charts, in CWM Advanced 2.2.1 (September 2026). Check your version, and what the charts count as complete, before building your own.³³
5. Don’t ask “ADO or CWM?”. Ask where each team’s work lives. ServiceNow configuration goes in CWM. Application code goes in ADO. Both roll up to SPM Pro.
6. The out-of-the-box ADO connector feeds Agile Development 2.0 (the rm_* tables), not CWM. It covers epics and stories. Sprints and bugs don’t sync cleanly, and direct ADO ↔ EAP integration is postponed to Q4 2026.¹⁸²⁰
7. LeanIX sits above delivery, not inside it. It syncs business applications with the CMDB. Delivery links to those applications through CSDM. Decide which system owns the application portfolio.

Why CWM sprints look like they’re failing

Teams move from Jira or Agile Development 2.0 to CWM and, within a sprint or two, decide it “can’t do agile”. Velocity reads a fraction of what was planned and stories sit on the board for weeks. Leadership sees a team missing commitments while it is actually shipping a lot of work.

The tool is rarely the root cause. If several of these are true, you have a coupling problem, not a CWM problem:

• Points only count at final closure. A story that is 95% built contributes nothing until it is fully closed.
• Done is tied to deployment. Stories only close when the release or change completes.
• Work spans many sprints. Items stay open for five weeks or more, waiting in UAT or for a deployment window rather than in development.
• Business delay is invisible. Reporting can’t separate a development delay from a business one, so the team takes the blame for both.
• Old stories fill new sprints. Every open story rolls into the next sprint, so capacity looks full of work that needs no development.
• Large items aren’t split. Big initiatives run as single oversized stories, not epics with sprint-sized stories sliced by the solution.

It’s two problems, not one. Sprint planning goes wrong because old stories keep taking capacity, and reporting goes wrong because it can’t tell development progress from business acceptance and deployment. Changing how velocity is calculated fixes only the second.

What other ServiceNow teams report

These are practitioner discussions in the ServiceNow Community, not generic agile advice. There’s no single method most CWM teams use yet. What they show is the same problems recurring.¹⁷

• How to track the sprint history (September 2026). A story developed in Sprint 1 is validated and deployed in Sprint 2. The team wants to count the sprints a story was in and spot stories added mid-sprint. Today they export the story list at the start and end of each sprint. The reply suggests metric definitions on the story and sprint tables.³⁷
• Managing after sprint is complete in CWM (September 2026). Stories stay on their original sprint, linked to a change or release. The CWM sprint doesn’t show on the classic story form, because CWM keeps it in its own tables.³⁸
• Carryover stories and points to next sprint (October 2024). A team built a carryover table for copied and split stories. Developers got round it by closing the story and opening a new one with slightly different wording, so the carryover disappeared. Recreating stories to tidy up reporting hides the problem.³⁹
• Start date / end date functionality in CWM board (July 2026). Adding the same story to two CWM boards creates two separate CWM records, each with its own dates.⁴³
• A lean (mean) ServiceNow release process (2013, by a ServiceNow employee). ServiceNow’s own developers had finished work waiting weeks for release and an overloaded UAT stage. It predates CWM, but it’s the same bottleneck. More in Managing the UAT queue.⁴⁰

How CWM maps to Jira

CWM gives each team a space with List, Kanban and Sprint Planning views, plus a backlog, story points, capacity, docs and automations.³ It replaces Agile Development 2.0 and shares the same Story table, so existing stories and epics appear through Connected Work without a migration.¹⁴

Separate delivery, acceptance and deployment

This is the core of the guide. “Closed story points” is being asked to mean three different things at once. Split them, each with its own metric and owner:

Two-tier Definition of Done

• Development Done (sprint DoD). Code complete and peer-reviewed, update set captured, documentation done, team QA passed. Development throughput is credited here. If your Definition of Done stops here, it’s also your velocity.⁶
• Done-Done (release DoD). UAT passed, change approved, deployed, business-accepted. Tracked on the flow axis. It doesn’t gate development throughput.

Name the three numbers

The Scrum Guide says work isn’t part of an Increment until it meets the Definition of Done.²⁹ So the key question is whether your DoD needs business UAT. If team QA is enough, points at Dev Done are velocity. If UAT is required, points at Dev Done are development throughput, and velocity comes at acceptance. Production deployment doesn’t have to line up with the sprint end either way.

Stories, update sets and changes

Why the story matters so much on a platform team

On a ServiceNow platform team the story is a unit of change as well as a planning item. Developers put the story number at the start of each update set, e.g. STRY0012345 – short description. When they prepare a deployment, they filter on that number and see everything that belongs to that piece of work. So changing how stories are structured also changes how the team deploys, which is why proposals to split stories often meet resistance.

The disagreement

When velocity looks low, two positions usually come up. Both have a point.

What best practice says

1. Stories should fit in a sprint. The Scrum Guide says items that can be Done within one sprint are ready for selection, and INVEST’s “Small” means small enough to fit an iteration.²⁹³⁰ A story that needs several sprints of development should be split.
2. Split vertically, never by the calendar or by layer. Each story should deliver something that works and can be tested. An integration, for example, can have one story per table or class being integrated, under an epic. Avoid “build it this sprint, finish it next sprint” and “one story for the UI, one for the script”.³¹
3. Don’t split work that’s only waiting. If development finished in one sprint and the story then sat in UAT, splitting it won’t help. Count development throughput at Dev Done instead (see section 6).
4. No partial credit. A story that is 95% built counts nothing until it reaches Dev Done.¹²¹⁴ Recording points when a story moves to UAT is fine, but only if reaching UAT means it has met the sprint Definition of Done.

Handling the update-set cost

Smaller stories do mean more update sets. The platform lets you keep deployment manageable without keeping stories large:

• Batch update sets under a parent. Give each story’s update set a parent. Committing the base update set commits the whole batch.³² One parent per epic or release keeps a deployment to one commit.
• Prepare deployments by epic or release. Filter on the epic or release to see everything that ships together. Story numbers still trace each individual change.
• Keep the naming convention. Story number first on each update set, epic or release number on the parent.

Story ↔ update set: keep it

ServiceNow practitioners document the same practice: one update set per story, with a naming pattern built from project, release, sprint and story, and only approved stories selected for a release.⁴¹⁴²

The story-number convention traces planned work to the exact configuration. It isn’t what hurts velocity, so don’t change it to fix a reporting problem.

Story ↔ change: link, but don’t gate

Nothing in ServiceNow requires a story to stay open until its change is implemented. That’s a local process choice, and it causes zero-velocity sprints. ServiceNow’s own DevOps Change Velocity creates changes from the pipeline, enriches them with stories and commits, and closes them on deployment.⁸⁹ The change trails the delivery, and ServiceNow treats traceability as a separate stage.¹⁰

Closing sprints and carryover

CWM doesn’t need a story to stay in its original sprint, or in every sprint after it. ServiceNow’s documented close is: select Complete Sprint, review the completed and open items, move incomplete items to the next sprint or the backlog, optionally create a retrospective board, then complete it.³⁴ The backlog then shows all unplanned work, including older incomplete items.⁵ So you need to tell work that needs development apart from work that is only waiting.

Why carrying everything forward distorts capacity

A hypothetical team plans 40 points a sprint. At the end of Sprint 74 it has handed three stories (24 points) to UAT, and none is accepted yet. Another 16 points are genuinely unfinished.

The UAT stories need no development in Sprint 75, so counting them again overstates the workload. That’s a planning problem, and it’s separate from when their points eventually count.

What to do with each kind of carryover

UAT rework without corrupting the numbers

Scrum tasks can’t carry rework into a later sprint. They inherit their parent story’s sprint, can’t be assigned to another sprint, and don’t roll percent complete up to the story.³⁶ For rework that’s separately estimable, create a defect or CWM task linked to the original story, and keep the story number in the update-set name. A minor fix can stay on the original story.

Don’t count the original 8 points again each time the story passes Dev Done. Record every return from UAT, and watch the rate: a high one can point to weak acceptance criteria, late stakeholder involvement or thin testing, but check each case. And don’t assume a story in UAT is 90% done. Rework can be large.

Two views, one set of records

• Active sprint: only work that needs the team this sprint: new development, active testing, UAT fixes.
• UAT and release queue, across all sprints: the original story, its update sets, UAT owner, days waiting and change reference.

Use the Sprint Planning view to allocate work and Kanban to track it.⁴⁶ Build both views as saved filters on the same board. A second board creates a separate CWM record for the same story, with its own dates.⁴³

Managing the UAT queue

Better velocity reporting can make the developers’ output visible while the UAT backlog keeps growing. In 2013 a ServiceNow employee described their own development team hitting exactly this: finished work waiting for release, long gaps between dev complete and production, and repeated UAT rework. They had overloaded UAT by pushing every finished item into it.⁴⁰

The fix wasn’t better Scrum reporting. They ran distinct stages (dev complete, ready for UAT, in UAT, ready to deploy, done), made the queue visible, pulled work into UAT instead of pushing it, flagged blocked items and measured time in each stage.

Will it even out on its own?

Only if acceptance keeps pace. If UAT is simply late by a steady amount, accepted points follow development a sprint or two behind. If the team hands over work faster than the business can check it, the queue grows. Work goes stale, developers revisit it, and context switching eats capacity.

• Each sprint, compare stories entering UAT with stories leaving it, whether accepted or rejected.
• Track the age of the oldest item waiting.
• Give every UAT item an owner and an expected response date.

Reporting in CWM

Check the native charts first

Sprint velocity, burndown and burnup charts arrived in CWM Advanced 2.2.1 in September 2026. Teams with EAP already had team-level sprint reporting.³³ The same month added configurable dashboards on each CWM board.⁴⁴ Earlier guidance said these were planned for H2 2026 and to use Performance Analytics until then, and practitioners expected Q4 2026.¹²¹¹

Before building anything, confirm your installed version. We couldn’t find public documentation on which state the native velocity counts as complete, whether Dev Done can be the counting point, or how a story reopened after UAT is handled. Test those on your instance. A native burndown may fix the missing chart without fixing your definition-of-done problem.

The data-model trap

CWM doesn’t use the old sprint data model. Flag this to developers before anyone writes a report:

Sprint, story points and acceptance criteria set in CWM aren’t written back to the classic story form.³⁵ The CWM sprint lives on the CWM work item, not on the story.³⁸ A report built on rm_story.sprint can be wrong even when the board looks right.

Capture history, not just current values

When a story moves from Sprint 74 to 75, a report on current values shows only 75. You lose the original commitment and the carryover. Record events as they happen:³⁷

This is a proposed design, not an out-of-the-box CWM schema. Metric definitions can record how long a field held each value, and scripted metrics cover the rest.⁴⁷ Metrics record changes as they happen, so start capturing now. For older sprints, rebuild what you can from audit history or exports, and label anything incomplete as partial. Check the field mappings on your version first.

Five reports

1. Development throughput per sprint.
2. Accepted completion per sprint.
3. Sprint carryover.
4. UAT ageing.
5. Scope change during the sprint.

Add a cumulative flow diagram of stories in development, in testing and awaiting acceptance. It shows the bottleneck better than a burndown. Reuse the native charts where they fit rather than rebuilding them.

CWM or Azure DevOps?

That question mixes up two separate layers: where teams execute, and where the PMO gets its portfolio view. Don’t mandate one execution tool. Mandate one roll-up point.

What the connector actually does

ServiceNow’s ADO integration syncs projects, teams, iterations and work items into Agile Development 2.0: epics, stories and sprints in the rm_* tables.¹⁹ In practice it centres on epics and stories. Bug → defect mapping is out of scope, and sprint imports are unreliable.¹⁸ The EAP route runs EAP → Agile Development → ADO, is officially interim, and can’t sync sprints. Direct ADO ↔ EAP integration is postponed to Q4 2026. Jira ↔ EAP has worked out of the box since December 2025.²⁰

So there’s no native ADO → CWM connector. What exists is ADO → SPM, and SPM is where the PMO wants the visibility anyway.

Side by side

The decision rule

• Teams whose deliverable is ServiceNow configuration (platform and admin teams) should use CWM. Their update sets, changes and catalogue items live on-platform. Traceability works natively and roll-up needs no connector. Starting CWM adoption with the platform team is the right instinct.
• Teams whose deliverable is application code should use ADO, which has better sprint tooling and sits next to the code. Their epics and stories reach SPM through the connector.
• Everyone rolls up to SPM Pro as the single view. Add EAP (Pro tier, replaced SAFe) if you need PI planning across teams.²²

The failure mode is forcing one tool for neatness. All-CWM hobbles code teams. All-ADO loses on-platform traceability for the ServiceNow team.

Upstream: from idea to project

Most work on a CWM or ADO board starts long before the sprint. An idea becomes a demand, the demand becomes a project, and each one syncs into SPM, where the PMO sees it. Fields only travel where a mapping carries them, so a value captured on the idea can disappear before it reaches the portfolio view.

Download PNGDownload SVGOpen full sizeRead the full guide

Where LeanIX fits

SAP LeanIX is enterprise architecture: capabilities, business applications, lifecycle and target state. It does not connect to CWM or ADO and plays no part in sprints. It integrates two ways with the ServiceNow CMDB, syncing business applications, IT components and discovered software, and can take its initial load from ServiceNow.²⁵²⁴

The chain runs: teams deliver work in CWM or ADO → against business applications in the CMDB, via CSDM → which LeanIX reads for the architecture view.²³ Get CSDM right, or the roll-up is built on sand.

Who owns what

The common pattern is to design capabilities and applications in LeanIX and keep operational CIs in the CMDB.²⁸²⁷

Integration checklist

1. Agree the system of record for each object type in the table above.
2. Tidy CSDM first. Business applications need owners, lifecycle and relationships to application services.
3. Decide the sync direction for each field, and which side wins a conflict.
4. Map LeanIX Application fact sheets to cmdb_ci_business_app, and list any other mapped tables.²⁵
5. Run the initial load in a sub-production instance and reconcile duplicates before going live.²⁶
6. Make sure every demand and epic in SPM references a business application, so delivery traces to architecture.

Setup guide

A low-risk sequence. Each step is small and reviewable, and none needs heavy customisation. Exact menus vary by release, so follow ServiceNow’s docs for yours.⁵

Phase 1 · Decide

1. Place each team. Apply the decision rule. List teams under CWM, ADO or “not agile yet”.
2. Check licensing: your SPM tier (Standard or Pro, and whether EAP is in scope), Performance Analytics entitlement and CWM version.²²
3. Agree the Definition of Done with development and business stakeholders, including whether it needs UAT. Define Dev Done, Accepted and Deployed. It’s a wording change with no platform risk.

Phase 2 · Configure CWM for platform teams

1. One space per team. Add members and link the team’s assignment group.
2. Connected Work filters. Bring in the team’s existing stories and epics, e.g. by assignment group and product.¹
3. Board columns that show all three axes:BacklogReadyIn progressPeer reviewDev Done ★In UATReady to deployDeployedMap the columns onto story states. Check which state your instance counts as “points completed”. If it can be aligned to Dev Done, do that. If not, report on transitions (option B or C).
4. Sprint cadence. Two weeks is the usual default. Create sprints in the Sprint Planning view and set capacity from availability.⁵
5. Reserve 20–30% of capacity for unplanned work on platform teams, and log interrupts as visible items.
6. Keep the update-set naming convention and story ↔ change links. Tell developers explicitly that deployment doesn’t change.
7. Remove any rule that stops a story closing until its change is implemented.
8. Close every sprint on schedule. Move unfinished work to the backlog, and keep UAT-only stories in the UAT queue view.³⁴

Phase 3 · Connect ADO for code teams

1. Configure the Agile Development ↔ ADO integration. Map ADO projects and area paths to ServiceNow teams.¹⁹
2. ADO is the master for execution fields. Don’t edit synced stories in ServiceNow.
3. Give every epic a parent in SPM. Link each synced epic to its demand or programme so it rolls up.
4. Test sprint sync, and accept the gap if it fails. The PMO needs epic and story progress. Sprint burndown stays in ADO.¹⁸

Phase 4 · Report and connect

1. Check for CWM Advanced 2.2.1 or later. Test what its native velocity counts as complete before building your own.³³
2. Start capturing history now: sprint membership and state transitions, on the CWM tables, not the classic story fields.
3. Build UAT ageing and development-vs-accepted first. Add carryover, scope change, say-do and cycle time next.
4. Link demands and epics to CSDM business applications.
5. Configure the LeanIX ↔ CMDB integration using the checklist in section 13.
6. Review carryover and UAT rework in every retrospective.

How to run a sprint

Definition of Ready

• Written as a user story with clear acceptance criteria.
• Small enough to reach Dev Done within one sprint, roughly no more than a quarter of the team’s capacity. Anything larger becomes an epic, split into vertical slices, not by sprint.
• Dependencies known, and a business UAT tester named.
• Linked to its epic, and through it to a demand and a business application.

Sprint planning

• Commit to the 3–5 sprint rolling average of velocity, adjusted for leave and the unplanned reserve.¹²¹³ Committing 150% guarantees a “failed” sprint on paper.
• Plan only work that needs the team this sprint. Re-estimate unfinished stories. UAT-only stories stay in the UAT queue.
• Keep refinement separate from planning. The PO owns priority and splitting. The team owns the commitment.

During the sprint

• Give every blocked item a reason and an owner. “Awaiting business UAT” is not the same as “awaiting a technical dependency”.
• Once a story reaches Dev Done it counts toward development throughput. Its journey to production continues outside the sprint.

Sprint review report

Retrospective

Use carryover to start a conversation about why work didn’t reach Done, not as a number to explain away. Partially done work is waste to understand, not credit.¹⁴

Metrics that beat raw velocity

Check before you commit

• ADO connector scope on your target release. If the PMO only needs epic and story progress, you’re fine. If it wants ADO sprint burndown inside SPM, that’s a gap.
• The Q4 2026 ADO ↔ EAP date. It has already slipped once. Plan without it.²⁰
• What CWM’s native velocity counts. Check your installed CWM Advanced version and which state it treats as complete.³³
• Whether your Definition of Done includes UAT. That decides which number is velocity.
• One team on CWM is a feature, not a failure. Extend CWM to teams whose work is on-platform and who can work in a genuinely agile way. Don’t extend it to code teams.
• The application portfolio’s system of record: LeanIX or ServiceNow EA. Decide before the integration goes live.

References

Checked September 2026. ServiceNow timelines change between releases, so confirm against current documentation and your own instance.

1. ServiceNow Community: Team-level agile planning in CWM · Velocity and burndown planned for H2 2026; Connected Work, Sprint Planning, points, capacity; scrum tasks on boards from March 2026.
2. ServiceNow Community: OOTB reporting for CWM · Product staff confirm velocity and burndown are not yet OOB; build from Performance Analytics meanwhile.
3. ServiceNow: Collaborative Work Management · Product overview.
4. DevSquad: ServiceNow Agile Development · Agile 2.0 → CWM deprecation: April 2026 End of Sale, support to 2030. Verify against the official ServiceNow KB.
5. ServiceNow Docs: Sprint planning in CWM · The backlog shows all unplanned work items, including older incomplete ones.
6. Scrum.org: Dev team velocity vs Scrum team velocity · Points are credited only when a story meets the Definition of Done.
7. Scrum.org: Moving Beyond Velocity · Velocity is a complementary practice, not core Scrum.
8. GitHub: servicenow-devops-change releases · Pipeline-created changes auto-close with actual start and end times.
9. ServiceNow Store: DevOps Change Velocity · Automatic change creation and approval from toolchain data.
10. ServiceNow Community: DevOps Change Velocity Quick Start · Traceability, registration and automation as separate phases.
11. ServiceNow Community: CWM, concerns about functionality · Practitioners: OOB burn-up and burndown not before Q4 2026; some teams stay on Agile 2.0 for reporting.
12. Atlassian: Sprint velocity in Scrum · A 90%-done story is not done; plan from a multi-sprint average.
13. TeachingAgile: Sprint velocity guide · Capacity-adjust commitments; velocity is a team metric, never individual.
14. Scrum.org: 4 misunderstandings about carryover · Partially done work is not credited.
15. Scrum.org: Velocity, a way to measure in Scrum · Velocity should never be a target.
16. ServiceNow Community: Sprint burndown chart · The PA Content Pack for Agile 2.0 gives burndown today; the CWM equivalent is in development.
17. ServiceNow Community: Collaborative Work Management · Practitioners describing stories that span sprints because they are coupled to change.
18. ServiceNow Community: Azure DevOps integration with SPM · OOB integration covers epics and stories; Azure bug → defect mapping is out of scope.
19. ServiceNow Community: Integration with Azure DevOps · Syncs ADO projects, teams, iterations and work items to Agile Development teams, sprints, epics and stories; sprint import issues reported.
20. ServiceNow Community: Integrating EAP with Jira or Azure DevOps · Interim route EAP → Agile Development → ADO; sprints cannot sync. Jira ↔ EAP OOB since December 2025; direct ADO ↔ EAP postponed to Q4 2026.
21. ServiceNow Community: CWM & EAP, agile planning at all levels · CWM and EAP share one data model; CWM is included in SPM Standard and Pro.
22. ServiceNow Community: SPM Pro vs Standard · EAP replaced SAFe in SPM Pro; check your tier under Subscription Management.
23. ServiceNow Community: CSDM’s relationship with APM, DPM and SPM · CSDM as the shared structure across APM, DPM and SPM.
24. ServiceNow Store: LeanIX Integration · Store listing for the integration.
25. SAP Help: SAP LeanIX ServiceNow integration · Two-way sync of business applications, IT components and discovered software; initial load from ServiceNow.
26. SAP Help: ServiceNow integration FAQs · Common setup and mapping questions.
27. LeanIX Community: ServiceNow APM module to LeanIX · LeanIX for strategic decisions, ServiceNow for operations; use both, integrated.
28. Coffee In Office: Combining CSDM with LeanIX · Capabilities and business applications owned in LeanIX; service instances and IT components in the CMDB.
29. Scrum Guide (2020) · Items that can be Done within one Sprint are ready for selection; work not meeting the Definition of Done returns to the backlog.
30. Agile Alliance: INVEST · Independent, Negotiable, Valuable, Estimable, Small (to fit an iteration), Testable.
31. Humanizing Work: Guide to splitting user stories · Split vertically for value and feedback; splitting by technical layer fails Independent and Valuable.
32. ServiceNow Community: How to create a batch update set · Child update sets take a parent; committing the base update set commits the whole batch.
33. ServiceNow Community: Start here, Agile 2.0 deprecation and CWM · Sprint velocity, burndown and burnup charts available as of September 2026 in CWM Advanced 2.2.1; EAP already has team-level sprint reporting.
34. ServiceNow Docs: Start or complete a sprint in CWM · Complete Sprint, review completed and open items, move incomplete items to the next sprint or the backlog.
35. ServiceNow Docs: Agile in CWM · CWM sprint, points and acceptance criteria aren’t written back to the classic story form; don’t use CWM and Agile 2.0 at the same time for the same stories.
36. ServiceNow Docs: Managing scrum tasks for stories in CWM · Scrum tasks inherit the parent story’s sprint; percent complete isn’t rolled up to the story.
37. ServiceNow Community: How to track the sprint history · September 2026. Story developed in one sprint, validated in the next; reply suggests metric definitions.
38. ServiceNow Community: Managing after sprint is complete in CWM · September 2026. CWM sprint is held on sn_cwm_task, not on rm_story.
39. ServiceNow Community: Carryover stories and points to next sprint · October 2024. A carryover table defeated by closing stories and recreating them.
40. ServiceNow Community: A lean (mean) ServiceNow release process · 2013, by a ServiceNow employee. Staged release process, pull into UAT, cycle time per stage.
41. ServiceNow Community: A simple deploy strategy for small teams · 2022, by a ServiceNow employee. One update set per story; names built from project, release, sprint and story.
42. ServiceNow Community: Releasing update sets across instances · Update sets tied to stories; only approved stories go into a release.
43. ServiceNow Community: Start date / end date functionality in CWM board · July 2026. The same story on two boards creates two sn_cwm_task records with separate dates.
44. ServiceNow Community: CWM Brazil updates, September 2026 · Configurable dashboards within each CWM board.
45. ServiceNow Docs: Agile Development sprint dashboard · Agile 2.0 sprint burndown, burnup and cumulative flow diagram.
46. ServiceNow Community: Migration guide, Agile Development 2.0 to CWM · Sprint Planning view to allocate, Kanban to track; start CWM sprints fresh at cutover.
47. ServiceNow Docs: Metric definition support · Field value duration metrics record how long a field held each value.