Analytics answers the questions you get asked in every sync: how far are we, what is at risk, and are we still on plan? This article explains each tab and the numbers behind it.
Where analytics live
More › Analytics opens a full-screen page with five tabs:
Tab | Answers |
Capability Progress | How much of each capability is landing this increment, and which ART carries it? |
Dependency Tracking | Which cross-ART dependencies are open? See Dependencies. |
Analytics | Progress by features, stories and story points per ART, burn-down, scope changes and sprint-by-sprint load. |
Risks (ROAM) | Which risks are open across every register of the solution, and how are they ROAMed? |
Tracking | Are we still landing what we committed at PI planning? |
The page opens on Capability Progress. If you refresh the browser it reopens the tab you were on; closing the page with × resets that.
ⓘ Which boards show which tabs
Capability Progress, Risks (ROAM) and Tracking are available on solution boards whose capabilities live in the capability backlog (every board created with the current wizard). Older solution boards show Dependency Tracking, Analytics and an Objectives tab instead.
Capability Progress
The default view, Measure against › This increment, answers “how much of each capability is landing this increment?”. The header shows how many ARTs (linked PI boards) and capabilities are involved.
Capability Progress, This increment, for seven capabilities across three ARTs.
Increment overview tiles
Count tiles by switches the five tiles between capabilities (default) and features. Clicking a tile filters the list; the first tile opens Capabilities by ART, a side panel of who carries what and the teams behind it.
Tile | Counts capabilities that… | Counts features that… (Feature mode) |
Capabilities in increment | have at least one feature on a linked PI board | are on a linked PI board |
In-increment planned | have at least one in-increment feature in a sprint | are in a sprint |
In-increment delivered | have at least one planned in-increment feature that is done | are planned and done |
Partially planned | have some in-increment features in a sprint and some not | are unplanned inside a capability that has started |
Unplanned work | have in-increment features but none in a sprint, or no children at all | are in the increment with no sprint |
When linked PI boards have features that belong to no capability, the list also includes a Features without capability row. The capability tiles do not count it.
The capability list
Capability: title, owner, a ★ when you watch it, the key and its source (Jira, Azure DevOps or Kendis). Synced capabilities show their Jira key or ADO ID.
Plan-state chip: Fully planned (every in-increment feature is in a sprint), Partially planned, Fully unplanned, No children yet or Not in increment (it has features, but none on a linked PI board).
Status: the capability's own status. Without one, it is derived from its features: all done reads Done, any started reads In progress.
In-increment burn-up: the green part of the bar is the share of the capability's features that are done and the light part the share in progress; the legend also marks unplanned work (no sprint) and the part beyond this increment. The text under it reads, for example, 5/9 done · 2 in progress · 3/6 delivered this incr · 1 unplanned · 2 ALM only. The headline percentage is green from 60%, amber from 35%, red below.
Per-ART: one chip per ART with its % delivered. Click a chip to list that ART's features, grouped by capability, with filters for status (including Slipping and Unscheduled), team, owner and sprint.
Expand a row
An expanded row: per-ART contribution, planned vs unplanned, scope churn and in-increment ratio.
Per-ART contribution: one stacked bar per ART (Delivered, In flight, Slipping, Unplanned) with delivered counts, slipping and unplanned features and the teams involved. When several ARTs carry the capability, the ART with the largest share is marked Long pole.
Planned vs unplanned this increment: in-increment features against those never pulled into a sprint.
Scope churn since plan: features linked (+) and unlinked (−) since the linked PI board entered the Tracking state. Before any linked board is in Tracking the counter waits for that moment.
In-increment ratio: the share of the capability's whole scope that sits in this increment.
Find, filter and act
Search matches capabilities and their features (key or title); matching features appear as chips on the row.
Group by: Capability (default), PI Board (with a No PI board placement group), Status, Planned / Unplanned or Scope changes (added, removed, none).
★ Watched shows only capabilities you starred here or watch on the card.
Drag rows to reorder them for yourself (Capability grouping, no search or filter). The list shows 15 rows per page.
Tick rows for the bulk bar: Change assignee, Update status and Export to CSV or Excel. Change assignee applies to Kendis capabilities and skips Jira and Azure DevOps ones. Update status needs the selected capabilities to share one workflow; for Jira and Azure DevOps capabilities Kendis writes the new status to the tool.
↻ Refresh re-pulls the children of Jira and Azure DevOps capabilities and recalculates. When the page loads, capabilities not synced for more than two hours are refreshed quietly in the background, once per page load.
How it is calculated
Term | Rule |
Done / in progress | The status category of the item in its own tool (Kendis, Jira or Azure DevOps). |
In increment | The feature is on the current board of a linked PI board. Older board versions do not count. |
Planned | The feature is in at least one team sprint on that board. |
Burn-up % | Done features ÷ all features of the capability, including ALM-only children. |
Delivered this increment | Done ÷ planned, for in-increment features. Unplanned work sits next to the bar, never inside the denominator. |
Per-ART % | Delivered ÷ in-increment features of the capability on that ART. |
Slipping | Planned, not done, and every sprint it is in has already ended. |
Capability Progress: whole capability view
Switch Measure against to Whole capability to see Capability allocation across increments: where each capability's features are planned over time and how each slice is progressing. It shows allocation as entered, not a forecast.
One column per increment that holds any of the capability's features (increments not on this solution board are marked not on board), plus Not yet scheduled for features with no sprint or board.
Each cell shows the share of the capability allocated there, x of y features or points, and a done bar (not started for future increments). Click a cell to see its features.
Distribution by: Feature count or Story points. Kendis features without points use the sum of their stories.
Type a capability and press Enter to pin it to the top and compare several side by side.
Analytics charts
The Analytics tab reports on the features and stories of every linked PI board. It is calculated on demand and stored; press Update Analytics to recompute. The time of the last run is shown under the button, with a reminder when the data is more than two days old.
Progress per ART and the story-point burn-down.
Progress by features, stories and story points: one bar per ART, done ÷ all items. The Planned switch (on by default) limits the count to items in a sprint.
Story points burn-down: for the ARTs you select, total story points falling per sprint against an ideal line. IP sprints are left out of the total.
Portfolio Epic Progress: a donut by capability status (To Do, In Progress, Done), feature status or story points. Capabilities without a status count as To Do.
Scope changes, current vs previous state: features and stories added or removed, added story points, and features or stories that changed sprint since the previous board state.
Sprint by sprint view: features, stories and story-point load per sprint against team capacity (sum of team velocities), and Session by session view: planned and unplanned items per ART. Each ART also has its own sprint-by-sprint section.
Almost every number opens the list of items behind it.
Risks (ROAM)
The Risks (ROAM) tab is the Solution ROAM register: one read-only list of the risks of every register linked to the solution board, including the registers that come in from linked PI boards. ROAM stands for Resolved, Owned, Accepted, Mitigated.
The Solution ROAM register with risks from two registers.
Which risks: from each linked register, the risks linked to this solution board or to no solution board, newest raised first.
Status chips: All risks plus one chip per status in use, with counts. Owned, Mitigated, Accepted and Resolved come first; registers with other workflow statuses show those names too.
Columns: ROAM status, the risk (key, a Jira or Azure badge when synced, risk level and register name), owner, Affects ARTs and raised → target dates.
Affects ARTs: the linked PI boards of the risk that belong to this solution. A risk not linked to any PI board lists every ART whose PI board uses its register.
Risk level: probability × impact placed on the register's own risk matrix.
Click a row to open the risk in its register's popup and edit it; the list refreshes when you close it.
To link registers, create risks or see risk charts, use the risk register itself; see Risks and risk registers.
Tracking against a planning baseline
Tracking answers “are we still landing what we committed this increment?” by comparing live data with a snapshot. The header shows the solution board and the current sprint (Sprint x of y).
Tracking compared with the End of PI planning snapshot: 4 of 7 capabilities slipping, 9 of 33 features delivered.
Snapshots
End of PI planning: the baseline. Kendis captures it automatically when a linked PI board moves to the Tracking state. You can also press Capture planning snapshot, or Retake planning snapshot to replace it. There is one per solution board.
End of Sprint n: captured the first time someone opens Tracking after that sprint has ended (marked captured late when that is more than a day after). Sprint snapshots are never overwritten.
Compare with lists all snapshots; the planning snapshot is the default and your choice is remembered per board.
If the board cannot be read completely, no baseline is captured, so a partial plan never becomes the reference.
The Compare with list: the planning snapshot, one snapshot per sprint, and Retake planning snapshot.
Reading the page
Are we on track?: On track, Slipping or Behind plan, from the worst capability. Click a verdict chip to filter the list.
Features landing this increment: delivered ÷ committed features.
Feature movement: four tiles; Delivered, In flight and Unplanned also show the change since the compared snapshot: Delivered (landed), In flight (in a sprint, on plan), Slipping (delivery sprint moved later) and Unplanned (in the increment, never pulled into a sprint). A line under the tiles reconciles them: committed = delivered + in flight + slipping + unplanned, plus the number descoped.
Descoped from the increment: features pulled out, with the sprint they were in. A feature that moved to another capability is marked Moved.
Capabilities this increment: per capability the ALM status, Kendis's tracking read, the delivery mix and the ART moving most. Capabilities with movement come first; quiet ones are collapsed. Expand a row for each feature's sprint movement.
Scope changes since planning: what entered the increment after the baseline and what left it.
Where the movement is concentrated: per ART, features moved, slipped and gone, and the teams involved.
The capability tracking lens, scope changes since planning and where the movement is concentrated.
How it is calculated
Term | Rule |
Delivered | The feature's status is in the Done category. |
In flight | In a sprint, on its planned sprint, not delivered. |
Slipping | Not delivered, and its sprint is later now than in the compared snapshot (shown as Sprint 2 → Sprint 4). |
Unplanned | On the board but in no sprint. |
Descoped | In a sprint in the snapshot and back in the backlog now (even if done), or removed from the capability since the snapshot. |
Added | Not in the compared snapshot. |
Capability verdict | Behind plan when at least 2 features and at least 20% of its committed scope were descoped; otherwise Slipping when anything slipped or was descoped; otherwise On track. |
Features are matched across board versions by their Jira key or ADO ID (or Kendis key), so draft and tracking copies of the same feature count once.
Two meanings of “slipping”
▲ Capability Progress and Tracking use different rules
In Capability Progress a feature is slipping when it is not done and every sprint it sits in has already ended. In Tracking it is slipping when its sprint is later than in the compared snapshot, even if that sprint has not ended yet. Use Capability Progress to spot overdue work today, and Tracking to see drift from the plan.
Frequently asked questions
I don't see Capability Progress, Risks (ROAM) or Tracking.
I don't see Capability Progress, Risks (ROAM) or Tracking.
These tabs are available on solution boards whose capabilities live in the capability backlog. Older solution boards show Dependency Tracking, Analytics and Objectives.
Capability Progress shows 0% although children are done.
Capability Progress shows 0% although children are done.
Check Measure against: with This increment only features on the linked PI boards count. Press Refresh to re-pull Jira and Azure DevOps children.
Why does a capability say “Not in increment”?
Why does a capability say “Not in increment”?
It has features, but none of them is on a linked PI board. Link the PI board, or check the Whole capability view to see where they are planned.
Scope churn stays at zero.
Scope churn stays at zero.
It counts from the moment a linked PI board enters the Tracking state. Before that there is no plan to compare with.
Why does the burn-down chart look empty?
Why does the burn-down chart look empty?
It needs stories with story points on the linked PI boards. Feature-only boards show progress by features instead.
The Analytics tab shows old numbers.
The Analytics tab shows old numbers.
The charts are stored after each run. Press Update Analytics; the time of the last run is shown under the button.
Tracking says no planning snapshot was captured.
Tracking says no planning snapshot was captured.
Move the linked PI board to the Tracking state, or press Capture planning snapshot. Until then you can compare with end-of-sprint snapshots.
I retook the planning snapshot by mistake.
I retook the planning snapshot by mistake.
There is only one planning snapshot per solution board, so the earlier one is replaced. Sprint snapshots are not affected.
A risk is missing from the Risks (ROAM) tab.
A risk is missing from the Risks (ROAM) tab.
Check that its register is linked to the solution board and that the risk is not linked to a different solution board.