Done vs Shippable
What's the difference, why mixing them up kill roadmaps, and how mature teams bridge this gap
I‘m pretty sure you’ve seen this happen.
Even when your team is hitting every “done” on the DoD, sometimes the release is nowhere near shippable.
“Product People” hear the words “Done” and “Shippable” all the time. These words are often used interchangeably. They are related.
But…
“Done” and “Shippable” are not the same thing.
And the distinction between the two affects everything from Sprint Reviews to release forecasts and roadmaps.
The best teams I’ve worked with obsessively bridge this gap…
But how?
How do mature teams keep “done” from derailing “shippable”?
And where should you focus if you want this to work for your team?
Let’s find out.
If you are new to Winning Strategy, check out the posts below that you might have missed
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
Why are the two terms used interchangeably?
In Scrum training, you hear:
“The Increment must be Done.”
“Every Sprint ends with a potentially shippable Increment.”
Because the phrases are often spoken in the same breath, teams start treating them as synonyms.
Which isn’t true!
What’s the difference?
The two terms are related, but not identical:
And they answer two different questions:
Here’s how you can make sense of it easily:
IF
Coded = baked
THEN
Done = baked + eatble (i.e. quality)
AND
Shippable = baked + eatable + boxed + labeled + has a tracking numberEverything Shippable is automatically Done, but everything Done is not Shippable.
Definition of DONE
As we already know…
Definition of Done is a checklist agreed upon by the whole Scrum Team. When any backlog item (story, bug, spike) satisfies all items in this list, the team may call it “Done”.
Example DoD list:
Code peer reviewed
Unit and integration tests are automated and green
Acceptance criteria passed
Documentation updated
Deployed to the integration (staging) environment
If an item fails even one of the above, it is Not-Done.
Definition of SHIPPABLE
“Potentially shippable” (Scrum Guide wording) is about the aggregate.
The Increment at the end of the Sprint is shippable when:
All included items are Done
AND:
It satisfies “release level” constraints like:
Security sign-off
Regulatory packaging (e.g. FDA)
Marketing/UX (versioning, copy, icons)
Operational readiness (monitoring, rollback scripts, feature flags)
Legal approvals
Contractual approvals
Most of these checks are organizational. Your PO ensures that these guidelines are transparent and well understood by the team.
What usually blocks “Shippable”?
External sign-offs: Legal, marketing, data-privacy, App-store approval
Operational readiness: Runbook creation, on-call training
Feature discoverability: Tutorials, in app messaging, website copy
Market timing: Embargoes, conference launches
These items are rarely inside a dev team’s DoD but affect release timing.
Example sprint
Let’s say the sprint ended last Friday.
The team can still say “Increment is Done” (assuming penetration test is outside DoD), yet the PO cannot press Release because of legal and release note gaps. Therefore, this increment is Not Shippable.
Why is it important to shrink the gap between the two terms?
Because there is a cost involved.
Every day the finished feature (after “done”) sits on the shelf instead of in users’ hands, the team pays a price in the form of:
Slow feedback from the customer
Release date confusion
Unknown risks
Lost competitive advantage
The smaller the gap between “We finished the feature” and “Users experienced the feature,” the faster the teams learn, the safer they ship, and the stronger the product advantage becomes.
How do mature teams spot the gap?
The gap hides in plain sight.
You, as a Scrum Master, can help the team spot the gap using the following three metrics:
These metrics provide you with the starting point for shrinking the gap.
How do they shrink it?
Below are some ways I have seen mature teams use to shrink the gap.
How mature teams shrink the gap?
Here’s what to do after the team has spotted the gap:
Make the gaps visible
Discuss in Retrospective. “What caused our Done to Shippable delay this Sprint?”
Once the team is aware of the gap, you can help them take one or more of the following actions.
#1: Cap “Ready for Release” column with a WIP limit
Set a strict WIP limit (e.g. 3 items).
When the limit is hit, the team stops starting and starts finishing. Everyone swarms on release prep instead of pulling new stories.
How to pick a limit?
“Pick a limit that hurts just a little”
Inspect history. How many “done” stories usually pile up?
If it’s 15, start with 5.
Make the number smaller than what feels comfortable. Enough to trigger action but not panic.
Define the “Ready for Release” column
A ticket only enters the column when:
It meets the Definition of Done and
All artifacts required for deployment are attached (migration script, release notes, feature flag default, etc.).
No partial work is allowed.
How does the team swarm?
When someone tries to add item #4 and the limit is already hit, do the following:
An immediate stop signal is sent (eg, Jira card colour change)
During Daily Scrum: “Our WIP is full, we need to finish shipping.”
Swarm responsibilities (examples)
Developers pair on deployment
QA engineers run pre prod smoke tests
PO preps comms and release notes
Scrum Master ensures the WIP limit is followed
Release or Flush
Once at least one item ships, the column is below the limit again, and new work may be started
WIP limit change the “Ready for Release” column from a parking lot into an action queue. This shrinks the gap between “done” and “shippable.”
#2: Expand DoD gradually
The basic Definition of Done is the team’s handshake that the code is complete for the Sprint.
Expanded DoD is the intentional practice of “widening” that handshake whenever the same release hurdle arises more than once.
“If it blocked us twice, automate it or absorb it into the DoD.”
Why twice?
Once can be a fluke
Twice is “something might be wrong…”
Example:
#3: Measure Lead Time to Shippable
“What gets measured gets improved. What gets repeatedly measured gets automated.”
What is it?
The elapsed clock time between a code commit (or merged PR) and the exact moment when that change is safely deployed to production. Inclusive of:
build,
test,
security gates,
manual reviews,
deployment, and
rollback validation
How it helps?
“Lead Time to Shippable” indicates every friction point in your pipeline. For example: slow builds, faulty tests, ticket queues, human hand offs, etc.
Short lead time = quicker feedback
Quicker feedback = lower rework cost
Lower rework cost = smaller Done-to-Shippable gap
#4: Measure % of releasable increments
For each Sprint, measure the ratio:
(# PBIs that meet both DoD *and* all release criteria) ÷ (Total # PBIs marked Done) x 100Target is ≈ 100%.
How do teams capture it?
Add a Releasable? (Yes/No) field to each PBI in your board
During the Sprint Review, the Scrum Master logs it in a simple table:
Display the % movement on the Confluence page
Two consecutive Sprints < 60% means the team must prioritize “release” impediment removal over new user stories
A sudden drop means you must ask, “What new release constraint surfaced that our DoD doesn’t cover?”
Note: Long Lead Time usually drags down % Releasable. Improving one should lift the other.
#5: Timebox external dependencies
Here’s what timeboxing means here:
1. Clear service level expectation (SLE)
For example:
Security review: 3 working days
Translations: 2 working days for French and German
2. Reverse scheduling
If the Sprint Review is Friday 16:00, anything that needs a 3 day Security Review is definitionally “development complete” by Tuesday 16:00.
A story that cannot meet that Tuesday cutoff is NOT Ready for the Sprint.
Or it must be split so that at least the risky part is ready.
Below are a few rules that I have seen teams following to make this work:
“Waiting for External” column with WIP limit 2
Anything stuck in this column triggers a daily Scrum shout out
Listing each external dependency, their SLE, contact, and escalation path in a shared space
If the story requires external X, evidence of the request sent by T-N days is mandatory
Timeboxing external dependencies turns them from impediments into scheduled, inspect and adapt elements of the Sprint.
This shrinks the Done-to-Shippable gap.
Role of a Product Owner
Here’s how you, as a Product Owner, can help the team shrink this gap.
#1 Treat “shippable” as an on/off business switch:
Mindset shift: “If I press the button right now, customers see value in < 2 h.”
Every Sprint end, you ask: “Could we release tonight. Yes or no? If no, why?”
#2 Optimize backlog for release flexibility:
Slice stories so each delivers independent customer value
Favour feature flags/configuration over branch-driven “big bang” releases
Negotiate external dependencies sooner (eg. legal wording, partner approvals)
#3 Release readiness checklist
Keep the checklist in the Definition of Done or as a Sprint board column
Update the checklist after every release retrospective
Example checklist:
All acceptance criteria pass
Spikes executed and signed off
Regression green for all impacted areas
Feature flags default to the post-release state
Unit, integration, and end-to-end tests ≥ 90% pass rate (or agreed threshold)
Non-functional tests (performance, accessibility, localization) meet targets
Code review completed. No “TODO / FIXME” comments remain
Role of a Scrum Master
Here’s how you, as a Scrum Master, can help the team shrink this gap.
#1 Protect the DoD
Make the DoD visible everywhere: Jira board, team wiki, etc
Conduct regular DoD refinement sessions. Add release constraints that repeatedly block releases (e.g. “API docs published”)
#2 Measure and surface the “Done - Live” gap using below metrics
Lead Time to Shippable
% of releasable increments (discussed above)
#3 Coach the team during Retrospectives
Use “5 Whys” on each gap. For example, “Why wasn’t the security test ready?”
Facilitate experimental change like:
adding WIP limits,
pairing with ops,
automating smoke tests, etc
Set up joint working agreements with security, legal, ops, etc., that create release constraints
So… what did we learn?
Done = “technically complete for the Sprint.”
Shippable = “valuable, safe, and supportable in the hands of real users.”
Your mission as “Product People” is to shrink the gap until the two terms become indistinguishable.
And this happens NOT by lowering the bar for ‘Shippable,’ but by continuously raising the bar for ‘Done.’
Show your support
Every post on Winning Strategy takes ~ 3 days of research and 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Further Reading
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.