Done vs deployed: when is a story actually finished?
Stefan-Iulian Tesoi · · 6 min read
A story is done when its acceptance criteria have been checked where they can actually be observed. For a backend change covered by tests, that can be the merge. For anything a user sees, it is after deployment, and behind a feature flag it is when the flag is on for the people the story was for. Merged is a step, not an outcome.
Most arguments about done vs deployed are arguments about where the evidence lives. Settle that per criterion and the argument mostly goes away.
Done vs deployed: where should the line sit?
At the point where the last acceptance criterion can be checked, which for most user-facing stories is production. A test can show that a billing total is calculated correctly. Only a deployed page shows that a customer sees the corrected total.
The Scrum Guide leaves room for this rather than settling it. "The moment a Product Backlog item meets the Definition of Done, an Increment is born," it says, and "in order to provide value, the Increment must be usable." Usable is not the same as in use. The Scrum Guide also says the Sprint Review "should never be considered a gate to releasing value", which treats release as its own decision. Whether release is part of done is the team's call, made in its definition of done, and most teams never write it down. What evidence a story needs is covered in the definition of done for agent-written code; the question here is where that evidence can be collected.
Why merged gets reported as done
Because the merge is the last event the tracker sees. A pull request merging into the default branch is a webhook every tool listens to. GitHub's closing keywords close an issue at exactly that moment: "Fixes #123" in a merged pull request marks issue 123 closed, whatever happens to the build afterwards.
Deployment arrives later and from somewhere else: a pipeline, a release train or another team's change window, which few trackers hear about. So the status moves at the merge, and the board reports work as finished that no customer can reach yet.
Merged vs released is the gap continuous delivery was built to shrink. With continuous deployment, every merged change reaches production within minutes and the two words describe the same afternoon. With a weekly release, they can be six days apart, and the board is wrong for all six.
The done-done agile shorthand exists because the first "done" so often meant merged, and the second meant someone had seen it working.
Where can each criterion actually be observed?
In one of four places, and the criterion decides which. Sorting each criterion this way before work starts settles the done vs deployed question for that story in advance:
| Criterion | Where it can be checked | Done at |
|---|---|---|
| Logic covered by tests | CI on the pull request | Merge |
| An API contract a consumer depends on | A staging environment, against the consumer | Staging or deploy |
| Behaviour a user sees | Production, or a deployed preview of the build | Deployment |
| Performance under real load | Production metrics | A measured interval after deployment |
| A change behind a feature flag | Production, with the flag on for the target audience | Rollout |
The table also tests the criteria. One that fits no row, such as "the export is improved", cannot be checked anywhere, which is a defect in the story. The same failure seen from the other side is when done and the repository disagree.
How do feature flags move the finish line?
They separate deployment from release, so deployed stops meaning in front of users. A change shipped behind a feature flag at 0% is in production and observed by nobody. Calling it done at deploy repeats the merge mistake one step later.
Three states are worth keeping apart:
- Deployed, flag off. The code is in production and nothing has changed for anyone.
- Released, flag on for the audience the story was written for. This is where the acceptance criteria can be checked.
- Cleaned up, flag removed. The branch in the code is gone and the old path is deleted.
The first two belong to the story. The third is separate work and deserves its own item, because a flag left in the code for a year is a second code path nobody tests.
What changes when agents merge several times a day?
The pile of merged but undeployed work grows faster, and the coding agent cannot see the end of it. An agent that merges eight pull requests a day into a repository that deploys on Fridays has up to forty changes waiting by Thursday afternoon, each one reported as done if the tracker closes at merge.
A coding agent's view ends at the pull request. It can run the tests and read the diff, but it cannot open the production page or read a flag's rollout percentage unless someone granted that access, and most teams rightly have not. Its work should reach In Review with the evidence it can produce, and close only once the criteria it could not observe have been checked.
Laimonade keeps the two facts apart. A coding agent connected to it cannot mark its own work done: it hands the item back with evidence, and the item lands in In Review. Separately, Laimonade marks an item Live only when every commit that delivered it is in a finished production deploy, read from the Cloudflare or Fly.io deploys the team connects, so done and deployed are two fields on one card rather than one word doing both jobs. The sprint workflow sets out who can move an item from In Review to Done.
A board that closes work at merge is measuring how fast code gets written. A board that closes it at observation is measuring how fast customers get what was asked for.
The second number is the one measuring whether coding agents are working needs. DORA metrics take the same position: the DORA guide defines change lead time as the time for a change "to go from committed to version control to deployed in production". The clock stops at production, not at the pull request.
Frequently asked questions
Should deployment be written as an acceptance criterion?
Not on every story. A definition of done deployment clause, written once, covers every story the team ships: "user-facing work is done when it is live and checked". Individual acceptance criteria should then describe the observable outcome, such as the total a customer sees, and the place to check it follows from the outcome. Restating "deployed to production" on each story adds words and no information.
What if the release happens weeks after the merge?
Then track merged and released as separate states rather than letting one word cover both. Close the development work on the evidence that exists at merge, and keep a release-level check for the criteria only production can show. A story parked in review for three weeks hides the real queue, which is the release, not the review.
Does waiting for deployment distort cycle time?
It makes cycle time honest. Measured to merge, it leaves out the wait for deployment, often the longest stage after review. Measure both: time to merge describes the team's flow, and time to production describes what the customer experiences. The difference is the cost of the release process.