Sprint goal achievement rate

Sprint goal achievement rate is the percentage of sprints in which a team fully achieves the goal it committed to at planning. If a team runs ten sprints and meets the goal in eight of them, its achievement rate is 80%. The metric is binary at the sprint level: the goal is either met or it is not, with no partial credit for almost.

The distinction from point-based metrics is the whole point. A team can complete most of its committed story points and still miss the sprint goal, because the unfinished items were the ones that actually mattered. Sprint goal achievement rate ignores volume and asks a sharper question: did the team deliver the outcome it set out to deliver. That outcome focus is what makes the metric resistant to busywork.

A strong achievement rate signals that a team can be trusted with a commitment to an outcome, which is what stakeholders and customers actually care about. It pairs naturally with sprint commitment accuracy, which measures how much committed work gets done. Achievement rate measures whether the right work got done. Together they describe both the volume and the aim of a team.

The calculation divides the number of sprints where the goal was met by the total number of sprints in the period, then multiplies by 100. The arithmetic is trivial. The discipline is in defining the goal well and judging it honestly.

1. 1

   The sprint goal

   A single, specific, testable outcome set at sprint planning. It describes the value the sprint will deliver, not a list of tasks. Without a clear goal, the metric cannot be judged.

2. 2

   Goal met or not met

   A binary judgement made at the sprint review against the agreed acceptance criteria. Mostly done counts as not met. The honesty of this call determines whether the metric means anything.

3. 3

   Total sprints in the period

   The full count of sprints over the window you are measuring, typically a quarter or a rolling set of recent sprints. This is the denominator.

4. 4

   Goals changed mid-sprint

   Cases where the goal was rewritten after the sprint began. Track these separately, because a goal that moves to match the outcome is not a goal that was achieved.

Because the per-sprint result is binary, the rate is only meaningful across a run of sprints. A single sprint is either 0% or 100%, which says nothing. Measured over a quarter, a rate of 80% or above shows a team that reliably hits its stated outcomes, while a rate that drifts below 50% means goals are being set the team cannot keep, or being disrupted before they can be kept.

A metric tree breaks the achievement rate into the reasons a goal gets missed, then ties each reason to the practice that controls it. A missed goal is rarely random, and the tree makes the pattern visible.

The first level separates three failure modes: the goal was set badly, the plan to reach it was wrong, or the sprint was knocked off course. Goal quality decomposes into how clear and how achievable the goal was. Planning decomposes into whether the work was understood and whether risks were surfaced early. Execution decomposes into disruption, blockers, and the team focusing on the wrong items first. Each branch has a different owner.

This structure turns a run of missed goals into a diagnosis. A team that sets clear goals but keeps getting derailed by incidents has an execution problem, not a planning one. A team whose goals were never realistic has a goal-setting problem that no amount of effort during the sprint will fix. The tree tells you which conversation to have.

There is no single right number, because the healthy range depends on how ambitious the goals are and how stable the environment is. A team setting stretch goals will run a lower rate by design, while a team in a noisy support-heavy domain will lose goals to disruption. The useful read is the trend and the cause behind any misses.

Always read this metric alongside the ambition of the goals. A 95% achievement rate on goals that barely stretch the team is worse than a 75% rate on goals that move the product forward. The number means nothing without knowing what was being aimed at.

Improving the rate is mostly about setting better goals and protecting the team is ability to pursue them. The work itself is rarely the problem. The problem is usually a goal that was wrong from the start or a sprint that was never allowed to stay on track.

The metric tree approach starts by reviewing several missed goals together and finding the branch they share. If they cluster on goal quality, the fix is in planning, not in working harder. If they cluster on disruption, the fix is in protecting the sprint, and no planning change will help.

KPI Tree lets you model this by connecting each branch of the goal achievement tree to the role that owns it. The product owner owns goal clarity and ambition. The team lead owns planning and sequencing. Whoever controls interrupt load owns disruption. With RACI ownership on every node, a run of missed goals stops being a generic team failure and becomes a specific signal pointed at a named owner. When achievement rate slips, the accountable owner is told, and the verified impact loop checks whether their change actually lifted the rate rather than just looking busy.

1. 1

   Setting goals that cannot be judged

   A vague goal can always be claimed as met. Without a clear, testable outcome and acceptance criteria, the metric is a self-graded exam and the rate is meaningless.

2. 2

   Rewriting the goal to match the result

   Quietly adjusting the goal mid-sprint so it matches what got done turns every sprint into a success. Track changed goals separately and judge against the goal as it stood at planning.

3. 3

   Giving partial credit

   Almost meeting a goal is not meeting it. The per-sprint judgement must be binary, or the metric drifts toward effort rather than outcome and loses its meaning.

4. 4

   Optimising the rate by lowering ambition

   Setting trivially easy goals to keep the rate high defeats the purpose. The metric only matters if the goals genuinely move the product forward.

5. 5

   Reading too few sprints

   A binary metric needs a run of sprints to mean anything. Judging the rate on two or three sprints reads noise as signal. Use a quarter or a rolling window.