The Say/Do Ratio: The Most Brutally Honest Scrum Metric

Your burndown chart is lying to you.

Velocity can be gamed. Story points are fuzzy. But there’s one metric that quietly exposes the truth about your team’s execution:

The Say/Do Ratio.

How much of what you said you’d do in a sprint did you actually get done?

Not re-estimated.
Not partially done.
Not "carried over but basically finished."

Done-done.

Most teams don’t like this number, because it’s brutally honest. And that’s exactly why you should use it.

What Is the Say/Do Ratio (Really)?

A Simple Definition

Say/Do Ratio =
(Work committed at sprint planning that is actually completed by sprint end) / (Total work committed at sprint planning)

Measured in story points, count of backlog items, or whatever unit you use consistently.

Example:

Team commits to 40 points at sprint planning
They finish 28 points by the end of the sprint
Say/Do Ratio = 28 / 40 = 70%

No special tools. No complex math. Just a mirror held up to your team’s promises.

Why It Matters More Than Velocity

Velocity tells you how much you did.
Say/Do tells you how reliable you are.

You can have:

High velocity, low Say/Do → fast but unpredictable
Moderate velocity, high Say/Do → steady and trustworthy
Low velocity, low Say/Do → slow and chaotic (the worst combo)

Stakeholders don’t just want speed; they want trustworthy commitments. A consistently high Say/Do Ratio (80–90% over time) builds that trust.

The Hidden Cost of a Low Say/Do Ratio

When your Say/Do Ratio is consistently under ~70%, you get:

Broken trust – Stakeholders quietly stop believing your sprint commitments
Chaos in planning – Constant spillover, re-negotiation, and re-prioritization
Team frustration – People feel like they’re always behind, never “winning” sprints
Fake predictability – Roadmaps and release plans built on wishful thinking

This isn’t about “holding people accountable” in a punitive way. It’s about confronting reality so you can improve.

How to Calculate Say/Do Ratio (Without Overcomplicating It)

Step 1: Freeze the Commitment

At the end of sprint planning, take a snapshot of what’s in the sprint.

List of stories / tasks
Story points or relative size
Clear definition of done

That’s your “Say”.

Important: Don’t quietly add a bunch of scope mid-sprint and pretend it was always there. If you add work later, track it separately.

Step 2: Measure Only Done-Done

At the end of the sprint:

Count only work that meets your Definition of Done
No partial credit
No 80% finished
No “just needs QA”

That’s your “Do”.

Step 3: Do the Simple Math

For story points:

Say/Do Ratio = (Points completed from original commitment) / (Points originally committed)

For item count:

Say/Do Ratio = (Items completed from original commitment) / (Items originally committed)

Track this every sprint and look at a rolling average over the last 3–5 sprints.

What a “Good” Say/Do Ratio Looks Like

Let’s be clear: 100% every sprint is not the goal. That usually means the team is sandbagging.

As a rule of thumb:

<60% – You’re guessing, not planning
60–75% – Unstable, lots of noise, hard to predict
75–90% – Healthy, realistic, getting reliable
>90% – Either very mature and stable, or under-committing

You want to live mostly in the 75–90% range over time.

What a Low Say/Do Ratio Is Really Telling You

When your Say/Do Ratio stinks, it’s not a “team is lazy” problem. It’s a system problem.

1. Your Sprint Planning Is Fantasy Football

If every sprint looks like:

Overcommit
Miss half of it
Carry it over
Repeat

Then planning is theater, not a serious forecast.

Symptoms:

Product Owner pushes for “just one more story”
Team members stay quiet instead of challenging estimates
No one looks at historical capacity or interruptions

2. Your Work Is Not Actually Ready

If half your sprint is blocked on missing designs, unclear acceptance criteria, or “we’ll figure it out later,” your Say/Do will suffer.

Common issues:

Stories without acceptance criteria
Backend dependencies not discussed
Hidden cross-team dependencies

You’re not bad at delivery; you’re starting with bad inputs.

3. You’re Ignoring Interrupt-Driven Reality

Some teams pretend they’ll have a clean 2-week runway, then get hammered by:

Production incidents
Sales “urgent” requests
Support escalations
Leadership-drive “can we just quickly…”

If you don’t plan for interrupts, your commitments are fiction.

4. Your Definition of Done Is Sloppy

If “done” means different things to different people, the Say/Do Ratio becomes meaningless.

Examples:

Devs say “done” when merged, QA disagrees
Testing and documentation carried to next sprint
Environments or releases lag behind the code

If you can’t agree on “done,” you can’t measure “did.”

Common Mistakes When Using the Say/Do Ratio

Mistake 1: Turning It into a Weapon

If leadership uses Say/Do to:

Compare teams
Punish low ratios
Demand 100% every sprint

…you’ll get gaming, fear, and fake numbers.

Say/Do is a learning metric, not a performance bonus metric. Abuse it and it becomes useless.

Mistake 2: Ignoring Mid-Sprint Scope Changes

Teams quietly add work mid-sprint, then:

Miss original commitments
Claim they “still did a lot”
Hand-wave away the gap

If you’re constantly adding scope, track it:

Original commitment = Say
Completed from original commitment = Do
Added mid-sprint = separate line item

Otherwise, you can’t see the real planning problem.

Mistake 3: Measuring Only in Story Points You Don’t Believe In

If your story points are:

Inconsistent across the team
Constantly re-estimated
Used as a proxy for hours

Then your Say/Do metric is built on sand.

Fix your estimation discipline first, or use count of items as a complementary measure.

Mistake 4: Obsessing Over One Sprint

A single bad sprint doesn’t matter. Life happens.

People get sick
Production blows up
A dependency slips

Look at trends, not isolated data points. The story is in the last 3–6 sprints, not the last one.

How to Improve Your Say/Do Ratio (Without Killing Morale)

1. Start by Making the Pain Visible

In your next few retrospectives:

Put the last 5 sprint Say/Do Ratios on a chart
Ask: “What does this say about our planning and predictability?”
Don’t assign blame; look for patterns

Concrete retro questions:

What surprised us this sprint?
What did we think we understood but actually didn’t?
What work should never have been in this sprint in the first place?

2. Base Commitments on Historical Capacity

Stop pulling numbers out of thin air.

Steps:

Take the average completed points (or items) over the last 3–5 sprints
Subtract a realistic buffer for:
- Known holidays / PTO
- Regular meetings / ceremonies
- Typical interrupts (based on history)
Commit to that number, not what you wish you could do

Example:

Last 4 sprints completed: 32, 28, 30, 26 → average = 29
You know next sprint has onboarding and a prod release
Commit to ~22–24 points, not 35

3. Make “Ready” a Gate, Not a Suggestion

Introduce a Definition of Ready (DoR) for stories entering a sprint.

A story is not allowed into the sprint unless it has:

Clear acceptance criteria
Design attached (if needed)
Dependencies identified
Test considerations discussed

If a story fails DoR, it doesn’t go in. Yes, that means telling stakeholders “no” sometimes. That’s how you protect Say/Do.

4. Reserve Capacity for Interrupts

If your team gets hit with interrupts every sprint, treat them as first-class citizens.

Tactics:

Look at the last 3 sprints: how many points / hours went to interrupts?
Reserve that capacity explicitly in planning (e.g., 20–30%)
Track interrupt work separately from planned sprint work

This turns chaos into forecastable reality.

5. Sharpen Your Definition of Done

Align the whole team on what “done” means:

Code written
Code reviewed
Tests written and passing
Deployed to agreed environment
Verified by QA (if applicable)
Documentation updated (if needed)

Write it down. Challenge work that’s pushed as “done” without meeting it.

6. Reduce Story Size (Relentlessly)

Oversized stories destroy your Say/Do Ratio because they:

Sit “in progress” for most of the sprint
Often spill over unfinished
Hide bottlenecks until it’s too late

Aim for stories that can be done in 1–2 days of focused work.

Ask in refinement:

Can we split this by user flow?
Can we separate backend and frontend?
Can we carve out a thin slice that still delivers value?

Smaller stories → smoother flow → more predictable completion.

7. Make Mid-Sprint Scope Changes Explicit

When you add work mid-sprint:

Call it out in a quick team huddle
Label it as “added scope”
Track its points separately

At sprint review, show:

Committed points vs completed (Say/Do)
Added scope and what got dropped (if anything)

This makes trade-offs visible and stops the illusion that “we can just squeeze it in.”

Using Say/Do Ratio in Retrospectives (Where It Actually Helps)

Turn the Metric into a Conversation Starter

Bring the Say/Do Ratio into your retro as a neutral fact:

“We committed 40, finished 24 → 60% Say/Do”
“That’s the third sprint under 70%”
“What’s behind this? Let’s map it.”

Then dig into:

Work type: Feature vs bug vs support
Blocked time: How often were we stuck?
Dependencies: Other teams? Vendors? Waiting on PO?

The goal: find one or two systemic changes to test next sprint, not to “try harder.”

Track Experiments Against Say/Do

When you run experiments (e.g., reserve interrupt capacity, enforce DoR), use Say/Do as a feedback loop:

Did it improve?
Did it stabilize?
Did it reduce stress?

This is where Say/Do becomes a continuous improvement metric, not just a dashboard number.

Tools That Can Help (Without Becoming the Point)

You don’t need a heavyweight tool to track Say/Do. A spreadsheet and your board are enough.

But if you’re already using tools for planning and retros, choose ones that make honest conversations easier:

Planning poker tools that avoid anchoring and groupthink
Retrospective tools that allow anonymous input so people can safely talk about overcommitment, pressure, and scope creep

For example, teams using ScrumPoi like that they can run quick, no-signup planning poker sessions and anonymous retros, and push decisions straight into Jira without ceremony getting in the way.

What Not to Do with Say/Do Ratio

Don’t chase 100% like it’s a high score
Don’t use it to compare Team A vs Team B
Don’t hide mid-sprint scope changes
Don’t ignore it when it’s uncomfortable
Don’t pretend re-estimating work upward is “improvement”

Use it to tell the truth about your system, not to enforce fantasy targets.

The Point of Say/Do: Less Theater, More Trust

The Say/Do Ratio is the most brutally honest Scrum metric because it cuts through the theater:

You said you’d do X.
You did Y.
Let’s talk about the gap.

If you treat it as a stick, your team will hide.
If you treat it as a mirror, your team will learn.

Stop obsessing over how fast you go. Start caring about how reliably you keep your word.

That’s where real agility starts.

The Say/Do Ratio: The Most Brutally Honest Scrum Metric