Everything you need to know about how Recadence works, what it requires, and what you can expect.
Recadence connects to Jira in read-only mode via the Atlassian APIs using an Integration User that you provide. It only retrieves data from projects you explicitly select for indexing. File attachments and binary content are never accessed.
You're in full control. You choose which projects to index, and you can flush indexed data at any time to remove historical records.
The Jira Plugin also respects your existing Jira permissions: users only see projects they already have access to in Jira. You can also request that AI Features be disabled entirely. For full details on data access and handling, see our Privacy Policy and DPA.
No. Your ticket descriptions and summaries are not exposed to external AI models. Issue descriptions and comments stay within our infrastructure and are never sent to third-party AI providers.
The only data transmitted to AI providers is anonymised operational metadata (like issue key IDs, workflow patterns, categorical facets and timing data) and any notes your team writes within Recadence, to generate summaries and insights within your account. If you'd prefer, you can switch off AI summarisation features altogether. For more detail, see our Privacy Policy and DPA.
All customer data is hosted on ISO 27001 and BSI C5 Type 2 certified infrastructure in the EU (Germany). Personal data and content data stays within the EU and UK (which has an EU adequacy decision).
Only anonymised, non-identifiable metadata (e.g. timing patterns and workflow transitions) may be processed by AI providers for summarisation. This data contains no ticket content or user identifiers, and cannot be traced back to your organisation. Full details are in our Privacy Policy and DPA.
We host on ISO 27001 and BSI C5 Type 2 certified infrastructure in Germany with no direct internet exposure, encryption at rest and in transit, logical tenant isolation between customers, and centralised identity management with role-based access controls.
We classify your data into tiers (operational metadata, content, and excluded) with different handling rules for each. Content data like issue descriptions is processed locally only and never leaves our infrastructure. Full details are in our Privacy Policy and DPA.
All personal data and identifiable content is deleted within 30 days of account termination. Backups containing deleted data are purged within 90 days. Security logs may be retained for up to 12 months for incident investigation purposes, after which they're purged too. Any data that's been irreversibly anonymised is not subject to deletion. For full retention and deletion terms, see our Privacy Policy and DPA.
Software engineering organisations of any scale who use Jira for delivery tracking. Organisations with multiple teams see the most benefit, but individual teams also gain significant insight.
Teams that get the most from Recadence fall into two categories: those struggling with slow cycle times, unclear bottlenecks, or low trust in metrics, and high-performing teams with mature CI/CD who want to catch exceptions early and pursue marginal gains.
Recadence connects to your existing Jira instance and reads your behavioural data. It doesn't replace anything. No agile framework changes, data migrations, or new workflows. Teams continue using Jira exactly as they do today; Recadence adds a layer of insight on top.
The only meeting Recadence requires is a regularly scheduled team retrospective, not framework specific.
Recadence supports Jira Cloud.
Any agile or waterfall framework is supported. Recadence focuses on agility outcomes (make tickets small, get frequent feedback) rather than enforcing any particular framework. You configure your working model in settings (Scrum, Kanban, Scrumban, or other Agile), and the analysis adjusts accordingly.
Recadence works with or without sprints. It adapts to how your team already operates. The term "sprint" in Recadence simply means a regular interval for reflection, regardless of whether the team uses sprints for planning.
For Kanban teams, Recadence creates rolling time windows anchored to your review date.
For Jira-managed sprints, if a sprint runs prohibitively long, it automatically reconstructs the sprint as it would have looked had it been closed on schedule.
Each team's project is configured independently. Recadence automatically infers most settings from each team's actual Jira behaviour: different frameworks, sprint lengths, statuses, ticket types, and roles are all supported. Teams just need to verify the mapping.
Recadence supports the vast majority of team configurations. There are a handful we've chosen not to support:
One team must equal one Jira project. Companies can still use Jira boards that compile multiple projects together, but analysis runs at the project level.
Epics, tickets, and subtasks should be used as intended. Some teams create tickets that are secretly epics, with subtasks acting as the real tickets. Recadence will guide teams away from this. It pulls information from subtasks but doesn't use them for cycle time. This is deliberate, to avoid noise from internal to-do lists.
Individual performance tracking is not supported or encouraged through the tool. Recadence analyses team-level behavioural patterns, not individual output.
Jira is our sole focus today to ensure depth and accuracy. Support for additional tools is on the roadmap based on customer demand.
Cycle time captures every queue, handoff, pause, and bounce a ticket goes through from start to release. A deterministic expert system analyses 100+ compound behavioural signals across your recent sprints to surface root causes: which ticket types become large, where work stalls, whether problems are outliers or systemic patterns.
The data points you to root causes. If multiple tickets took too long in code review, or bounced out several times, or sat in QA for days with bug tickets created against them, the specific code syntax doesn't change the team-level decisions about reducing cycle time. The individuals discuss the specifics that relate to impact against a shared cycle time objective.
No. Recadence works instantly, even with bad Jira hygiene. It automatically cleans duplicates, infers settings from your behaviour, and maps your existing workflow to canonical categories. You verify what it finds in about five minutes.
Recadence flags when data is missing and factors it into the analysis. If 50% of tickets aren't estimated, that shows up as a pattern correlated with larger cycle times. If no externally-blocked status is configured, the tool highlights the cost of that gap.
There's also a self-correcting dynamic: not recording things hurts the team if their goal is to reduce cycle time. The data makes the invisible visible, and teams naturally fill the gaps that matter.
Recadence is designed for real-world Jira data, not idealised data. It tracks reverts to "To Do" statuses after work begins, temporary resolutions, and paused tickets. It distinguishes between active work and queued time. The analysis focuses on patterns across sprints rather than individual anomalies, so one-off errors don't distort the findings.
Recadence automatically infers settings from your behaviour, and unverified values continue to change as new patterns are detected. Verifying or manually setting a value locks it in place. The analysis focuses on the most recent four sprints, so it naturally adapts to how the team is working now.
The consequences of code-level problems (long development times, batched releases, merge delays) all manifest in Jira ticket lifecycle data. Recadence measures the outcomes and the systemic patterns that drive cycle time.
For some teams (e.g. API teams with strong CI/CD and automated testing), PR bottlenecks may be the primary remaining concern. In those cases, it's worth checking whether PRs are actually the bottleneck by looking at the entire cycle time first. Recadence surfaces where time is really going, so teams can invest in the right specialised tooling with confidence.
Release Cycle Time is the working days from when planned work starts until it is released. The clock starts when a ticket first enters an in-progress status and ends when it reaches a resolved status (typically deployed to production). Crucially, the clock does not stop for internal blockers, queues, pauses, or reverts.
From a team outcome perspective, once work meaningfully starts, all of that time represents delivery capacity being consumed. Time in backlog/to-do before first starting is excluded.
The primary risk threshold is DORA-informed: average Release Cycle Time should be less than half a sprint. This threshold exists because if work routinely takes longer than half a sprint, the team cannot leverage feedback loops effectively. They can't reflect, adapt, and improve within a retrospective cycle.
Teams can adjust sprint lengths and other settings, but the principle is fixed: if you can't complete and release planned work frequently enough to demo progress each sprint, your feedback loops are too slow.
Recadence uses a two-layer approach. First, a deterministic expert system correlates hundreds of behavioural signals across the last four sprints to find compound patterns and root causes. This is not AI opinion.
Second, an LLM distils these results into discussion prompts and two-minute briefs tailored to the team's specific data. The AI summarises and explains; it doesn't invent. Every recommendation traces back to measurable patterns in the team's own Jira data.
Every recommendation is backed by specific data from the team's own Jira history: exact tickets, percentages, and correlations. For example: "Tickets are 92% more likely to become large when the developer role is 'BE-team'" or "25% of delivered planned work was spent in peer review." Teams can drill from a summary finding down to individual tickets.
The recommendations are grounded in the team's own data, not general best practices. The expert system identifies statistical patterns, and the AI translates these into actionable language. Teams verify accuracy against their lived experience in retrospectives. Because the underlying analysis is transparent, they can challenge or confirm any recommendation with evidence.
Cycle time is the primary measure: if an optimisation works, cycle time goes down in the next sprint. If it doesn't, cycle time goes up or carry-over builds, and that's okay, because it failed fast.
The four balanced metrics (Release Cycle Time, Tickets Released, Defect Rate, Defect Recovery Time) prevent teams from shifting problems elsewhere. Recadence also tracks structural health signals like WIP creep, external blocker growth, reactive work trends, and defect backlog build-up.
The four balanced metrics make gaming counterproductive: improving one at the expense of another is immediately visible.
The hard problem is measuring "value" directly. It's a lagging indicator, and different roles tend to invent competing proxies. The Agile Manifesto has always been clear: working software is the primary measure of progress. The best leading indicator of value is qualitative, not quantitative, which is why cycle time matters. Without a short enough release cadence, there's no regular opportunity to evaluate whether the work being delivered is actually valuable.
Recadence helps teams get their average release cadence under a week, establish regular user feedback, and showcase the top 5-7 value-oriented things they released in stakeholder demos every couple of weeks.
No. It reads your existing Jira data and adapts to whatever it finds. Over time, teams may evolve their process based on what the data reveals (like adding a "Ready" status or distinguishing external blockers), but that's team-led, not tool-imposed.
Recadence is generally welcomed by teams because the expectations it sets are reasonable, and it does the heavy lifting to help teams meet them. The primary target is an average Release Cycle Time of less than half a sprint, for most teams roughly a week on average.
It also protects teams from outside factors: external blockers, reactive interruptions, and dependency delays are measured automatically, giving teams data-driven arguments without requiring manual analysis or admin. Where there is initial hesitation, it typically resolves once individuals see the data applied to their own situation. Engineers dealing with frequent disruptions, high WIP, or disproportionate time lost to quality issues see those patterns reflected clearly.
The four balanced metrics prevent one-sided optimisation: if a team improves cycle time at the expense of quality, the defect rate will show it. The team must own both the strategy and execution of staying within risk thresholds in order to reflect and adapt. Teams discuss findings in retrospectives and agree on the smallest improvement worth testing.
Setup takes about five minutes. Ongoing, Recadence directs teams in their retros towards the exceptions: the tickets and systemic issues that are most impactful. Each sprint analysis includes two-minute briefs for quick review, plus 10–15 minute guides for deeper investigation when needed.
The return is proportionate: if using the tool avoids even one wasted sprint due to earlier user feedback, the time saved far outweighs the investment.
Most dashboards show activity metrics without explaining what's wrong or what to do about it. Recadence lives inside Jira (via a plugin), surfaces root causes rather than raw data, and is designed to be used in retrospectives, not stared at on a wall. It answers "why is this slow?" and "what should we try next?" rather than displaying charts the team has to interpret themselves.
Recadence makes overload visible. It tracks WIP limits, context switching, scope creep, and reactive interruptions, all leading indicators of burnout. When individuals are consistently overloaded, the data provides hard evidence, not opinion, that can be correlated to lower throughput. Teams can use this to push back on unsustainable expectations with measurable impact.
No. Individual names aren't used in reports. Team roles are used instead (e.g. "QA" or "Front-end Developer"). Singling out individuals in a retrospective is more likely to cause collaboration problems than solve them.
A cycle time rising above a risk threshold isn't a problem in itself; it's when it rises with no explanation that it's a problem.
Recadence initially loads invisibly, available only to management. It is then introduced to teams, who are sometimes given an adjustment period, a window where the focus is on understanding the data rather than acting on the numbers. The tool gives teams the data to own their narrative and communicate impact with evidence rather than anecdotes.
When cycle time is consistently low, scope changes become cheap course-corrections instead of expensive surprises. Transparency through regular demos of released work builds trust on cadence, not promises. When project sponsors can see outcomes every sprint, they gain the context to make scope, time, and dependency trade-offs throughout the project, rather than relying on upfront plans that rarely survive contact with reality.
In practice the opposite tends to happen, especially after several demos of released value. When demos ceremoniously only show released, production-ready work, stakeholders respond to reality rather than speculation. Course-correcting small, released increments is an order of magnitude easier than debating long-term plans. The key rule: only present work that is live in production, never work that is "almost finished."
The goal is released work to show, not explanations of why nothing shipped. Recadence helps teams reduce their cycle time in phases, until they're able to achieve this. While you can't easily measure value directly, when a team doesn't feel confident showcasing what they've built, that's a signal there may be a deeper issue worth exploring first. Recadence helps surface what that issue actually is.
Your existing reports and dashboards will still work, and they'll just get better. When work is broken into small, frequently released increments, predictability improves and epic-level reporting is easier to communicate without complex tooling.
The DORA-aligned top-level metrics in Recadence give leadership a consistent view of delivery health. For many teams, the best leading indicator of value is qualitative, which is why regular release demos complement the metrics rather than being replaced by them.
Five minutes. On a setup call, we connect your Jira, pick a team, and Recadence automatically maps your project configuration: statuses, ticket types, team members, and roles. You verify the automatic mapping, and your first analysis is ready. No code access, no repo permissions, no data migrations.
Your team's behavioural history, focused on the last four sprints. This includes where time actually went across your workflow, what was planned vs. reactive, where work stalled, and which tickets were large or problematic.
The "What" section shows exactly what happened. The "Why" section reveals root causes across seven areas (large tickets, planning, testing, workflow/CI-CD, team overload, tech debt, external factors), providing recommended actions with AI-generated briefs.
It's an ongoing diagnostic system, not a reporting tool. Recadence provides powerful insights during the initial analysis, but its real value is continuous. It analyses each sprint, so teams use it in every retrospective to track whether changes are working. Adaptability matters more than getting it right first time.
They see different views of the same underlying data. Teams see sprint-level detail through a Jira plugin: blockers, scope changes, handoff delays, and per-ticket analysis with AI-powered recommendations. Management sees outcome metrics: cycle time trends, release cadence, defect rates, and structural health signals. Both views are grounded in the same data, so conversations stay aligned.
The expectation of risk thresholds is owned by engineering and product leadership. Meeting those expectations, and explaining when they can't be met, is owned by the team. Recadence does the heavy lifting for both: it gives managers visibility into delivery health, and gives teams the evidence and guidance to improve progressively.
Teams already close to good practices can see measurable improvement within one to two sprints. Even a small optimisation should show up in the next sprint's Release Cycle Time. The key is to start with the smallest improvement worth testing.
Reduced cycle time within one to two sprints, improved DORA-aligned metrics across delivery and quality, fewer carry-overs, and better focus. Once release cycle time improves, stakeholder and project sponsor trust also improves. When teams can show evidence for why something is slow and what they're doing about it, conversations shift from blame to collaboration.
Faster time to market, quality as a delivery enabler, and future-proof measurement.
A Scrum team releasing in two-week batches, with two weeks to schedule follow-up and two more to release it, has a six-week feedback loop, roughly eight chances per year to respond to customer feedback. A competitor on weekly cycles gets over fifty. Recadence helps teams close that gap progressively.
Recadence also measures the downstream impact of quality issues on the team's ability to deliver new work. Making that cost visible lets teams and stakeholders make informed trade-offs rather than short-changing quality by default.
Different teams need different levels of support. Recadence provides visibility and guides teams to fixes through continuous improvement. We also provide direct support when teams run into unique challenges, and work with a network of partners and external coaches for teams that need deeper engagement.
The initial analysis is free as part of a setup call. It will surface bottlenecks and quick wins in key areas. Pricing is based on team size and level of support. Contact hello@recadence.ai or book a call.
The initial analysis is free as part of a setup call. We then discuss trial and pilot options based on what the data reveals and what makes sense for your organisation.
You can start with one team. Each team's project is configured independently, so there's no requirement to roll out across the organisation. Starting with a single team is common. It lets you see results quickly and build an internal case for wider adoption.
No long-term commitment is required upfront. We discuss flexible options after the initial free analysis. Contact hello@recadence.ai or book a call for details.
DORA metrics tell you what your performance level is. Recadence tells you why and what to do about it. DORA measures outcomes but doesn't explain the behavioural causes behind those numbers.
Recadence traces tickets through their entire lifecycle, correlates 100+ compound behavioural signals, and surfaces root causes: which ticket types become large, which roles create bottlenecks, whether planning dysfunction or workflow queues are the real driver. It uses DORA-aligned risk thresholds to set team goals, then pairs them with the diagnostic depth needed to actually improve.
Pulse surveys capture how teams feel. Recadence captures what teams do. Surveys have their place, but they are also subjective, periodic, and prone to response bias. Teams might say "we're fine" while their data shows 30% of cycle time lost to queues.
Recadence provides objective, continuous, evidence-based analysis that teams can act on immediately in retrospectives. The two are complementary, but surveys alone can't tell you where time actually goes or what specifically to fix.
Custom Jira reports show you what happened at a surface level: ticket counts, velocity charts, burndowns. They don't explain why cycle time is high or what to do about it.
Recadence automatically maps your configuration, cleans inconsistent data, correlates compound patterns across sprints, and produces root cause analysis with evidence-backed recommendations. It also distinguishes between time the team controls and time lost to external factors, something standard Jira reports can't do without significant manual effort.
DevOps monitoring tools focus on the engineering pipeline: CI/CD performance, deployment frequency, code-level metrics. Recadence focuses on the team delivery system: planning dysfunction, product/QA bottlenecks, cross-role collaboration problems, external dependencies, and the behavioural patterns that drive cycle time.
If code review consumes 25% of your cycle time, you'll see it. If scope creep is the real issue, you'll see that too. DevOps tools answer "is the pipeline fast?" Recadence answers "why isn't the team delivering?", which is often a people and process question, not a tooling one.
We'll walk you through your first analysis on a quick setup call. Five minutes, your data, no slides.
Connect your data