Step 1. See it: Measure what matters.
On a setup call we connect a read-only Jira user and pick the teams to review. Recadence maps your statuses, ticket types and team roles from the change history already in your tickets, and you verify the mapping. That is the whole configuration. The first thing you see is your own last quarter, not a demonstration. There is no dashboard to build first.
It loads invisibly at first, available only to management. Teams are introduced when you decide they should be, by adding the Jira plugin.
Everything is read from Jira change history: how work moved between statuses and how long it waited at each one. Every one of those moves was a decision the team made that day about what to prioritise. It is behavioural data, not individual activity data. Recadence doesn't look at how many commits or pull requests anyone produced along the way.
What the number is made of
If you only measure one thing, measure the cost of being delayed. Release Cycle Time is the working days from when a ticket first starts in progress until it is released. It counts working days because each workday is a priority decision, and weekends are usually not.
Once a ticket meaningfully starts, the clock doesn't stop, especially when it's blocked.
Cycle Time goes up when delivery is disrupted. It comes down when things improve. And it is resistant to gaming: the only way to sustainably reduce it is to release more often, making priorities more transparent.
This metric reflects team outcomes, not individual performance. Individual names aren't used in reports; team roles are used instead (e.g. "QA" or "Front-end Developer").
The days spent waiting on another team are included in the count. So are the days after the ticket was reverted to To Do, and the days it sat between review and test. From a team outcome perspective, once work has meaningfully started, all of that time is delivery capacity being consumed. If the number left the external block out, it would say the ticket took less time than it did, and the team would have no evidence of what that dependency cost them.
Four metrics that balance each other
Release Cycle Time
Planned work shouldn't take more than half a sprint.
Tickets Released
Small, frequent releases are the foundation.
Defect Rate
Speed without quality creates more work, not less.
Defect Recovery Time
When something breaks, how fast does the team recover?
These four DORA-influenced metrics balance each other. Optimising one at the expense of another always shows up. The only way through is to genuinely improve.
Signals to offer support, not surveillance
Underneath the four, Recadence tracks over a hundred behavioural facets of how each team's work moves. Engineering leaders are shown a small set of them as structural health indicators: WIP creep, external blockers growing, reactive work consuming capacity, defect backlog build-up, unfinished carry-over, cancelled work. They tell you when something needs attention, so you know when to step in and offer a team support without chasing updates or depending on self-reporting.
Some teams measure themselves against industry benchmarks, but every team, every project and every company is a different situation. The most useful benchmark is how the team itself has performed so far, because that is the one it can continuously improve against. Recadence builds that baseline from the history already in your Jira, in one pass, for every team you point it at. It is the basis on which the impact of AI adoption, a change in team structure or hypergrowth can be measured, particularly against risk thresholds.
If a diagnostic is all you need, this first step is enough on its own. The next two are for when a team wants to improve on the evidence in front of them.
