• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Planned vs. Completed Work Ratio

Description

Planned vs. Completed Work Ratio measures the proportion of work a team commits to at the beginning of a sprint or timebox that is actually completed by the end. This is a core metric for assessing delivery predictability and commitment reliability in Agile teams.

A consistently high or improving ratio indicates good planning, focus and flow. A low or highly variable ratio may signal overcommitment, delivery blockers, or poor estimation discipline.

How to Use

What to Measure

  • Planned Work: The total story points, work items, or estimated effort committed at the beginning of a sprint or iteration.
  • Completed Work: The subset of that planned work that is marked “Done” by the end of the sprint (per Definition of Done).

Track this ratio per sprint, and trend it over time to assess team predictability.

Formula

Planned vs. Completed Ratio (%) = (Completed Planned Work / Total Planned Work) × 100

For example:

  • 30 story points planned, 24 completed → 80% ratio
  • 10 stories planned, 8 completed → 80% ratio

You may also track:

  • Stretch Goals: Work taken in but not part of the initial commitment.
  • Unplanned Work: Work not planned at the start but completed during the sprint.

Instrumentation Tips

  • Ensure consistent tagging of sprint scope in tracking tools (e.g. Jira sprints).
  • Apply Definition of Done rigorously to count only fully completed work.
  • Exclude spillover items or carried-over work unless re-planned deliberately.
  • Visualise trends using bar charts or control charts.

Benchmarks

Benchmarks vary by team maturity and working style:

Ratio (%) Interpretation
90–100% Very predictable, strong planning discipline
70–89% Healthy, especially if consistent
50–69% Some overcommitment or delivery friction
<50% Unpredictable, likely issues in planning focus

Consistency is more important than perfection. A stable 80% is healthier than swinging between 50% and 100%.

Why It Matters

  • Builds trust
    Consistent delivery against commitment improves confidence from stakeholders.

  • Supports sustainable pace
    Encourages right-sized planning that balances ambition with realism.

  • Informs planning improvements
    Data from this metric helps teams tune estimation, capacity and work breakdown.

  • Detects systemic issues
    Variability can signal deeper problems like unstable priorities or unclear scope.

Best Practices

  • Review this metric as part of sprint retrospectives.
  • Make realistic commitments based on historical throughput and capacity.
  • Encourage a culture of finishing, not just starting, work.
  • Limit mid-sprint scope changes unless driven by critical needs.
  • Track unplanned or stretch work separately for context.

Common Pitfalls

  • Counting partially done work as “complete”.
  • Over-relying on this metric and incentivising conservative commitments.
  • Ignoring external disruptions or organisational causes of low completion.
  • Not analysing why gaps exist between plan and actual.

Signals of Success

  • High and stable ratio of completed to planned work over multiple sprints.
  • Stakeholders can confidently rely on sprint outcomes.
  • Teams improve planning and prioritisation using this metric.
  • Unplanned work is visible, limited and managed deliberately.

Related Measures

  • [[Forecast Accuracy (Story Points or Item Count)]]
  • [[Sprint Goal Success Rate]]
  • [[Delivery Commitment Confidence Score]]
  • [[Work Replanning Rate]]

Aligned Industry Research

  • Scrum Guide
    Encourages empirical planning and commitment based on historical data.

  • Agile Estimating and Planning (Mike Cohn)
    Recommends using velocity trends and completion ratios to improve planning accuracy.

  • Evidence-Based Management (Scrum.org)
    Suggests monitoring the reliability of delivery against commitment to inform decision-making.

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering