What done should mean for a sprint ticket

Written By: BrainSoft In Engineering

Most arguments about a ticket's status are not really arguments about the work. They are arguments about what the word "done" was supposed to cover. I've watched a card sit in review for three days because nobody agreed whether a migration script counted as part of the feature, and I've seen a story marked complete while the endpoint it added had never been called by anything outside a unit test.

A ticket is done when it is merged, deployed to the environment the team treats as real, and verified there against its acceptance criteria, with tests, review and any migration or config change included. Write that down once per team and the status column stops being a negotiation.

The three checkpoints I actually use

I find it helps to split done into checkpoints rather than one vague finish line. The first is code complete: merged to the main branch, reviewed by someone who did not write it, and covered by tests that would fail if the behaviour broke. The second is deployed: the change is running somewhere a colleague can open in a browser or hit with curl, not just sitting in a build artifact. The third is verified: the person who accepted the ticket walked the acceptance criteria on that deployed build and saw the expected result.

The gap between the second and third checkpoint is where most of our rework came from. Teams tend to treat a green pipeline as proof the feature works. It proves the code compiles and the tests that exist pass. It says nothing about whether the new field shows up on the invoice screen for a customer with two subscriptions.

Code complete means merged, reviewed, tested, and no leftover TODO that the ticket depends on.
Deployed means running on a shared environment, with migrations applied and config or secrets in place.
Verified means someone checked the acceptance criteria there, and wrote down what they checked.

Make the ticket say what finished looks like

A ticket with a clear acceptance section does most of this work before anyone writes code. I write it as observable statements: given a logged-in user with an expired card, the billing page shows a red banner and the retry button posts to the renewal endpoint. That is checkable. "Improve billing error handling" is not, and it will be argued about on the last day of the sprint.

For anything touching infrastructure or data, the ticket also needs to name the operational steps. A schema change is not done until the migration has run on staging and someone has confirmed the old code still reads the table during the deploy window. I put those steps in the ticket body so the reviewer sees them in the diff context, not in a chat thread that scrolls away.

## Acceptance
- [ ] POST /api/renewals returns 402 for an expired card
- [ ] Billing page shows the retry banner for that response
- [ ] Migration 0042 applied on staging, old code still reads
- [ ] Verified on staging by someone other than the author

That last line matters more than it looks. Self-verification is fine for a one-line copy change. For anything with a user-facing path, a second pair of eyes on the deployed build catches the things unit tests are blind to: layout, permissions, empty states, and the awkward data the fixture never had.

What does not belong in done

There is a temptation to fold everything into done until the definition becomes unusable. Documentation for a public API is part of the ticket. A full monitoring dashboard for a new service usually is not, and pretending otherwise means the ticket never closes. Same with performance work that has no stated target, or cleanup of adjacent code the change happened to touch.

When a team is unsure, I ask a blunt question: if we shipped this exactly as described and never touched it again, would anything break or confuse a user? If yes, that thing is in scope. If it is a nice-to-have, it gets its own ticket and its own priority. This keeps the definition short enough that people actually apply it. If your team is wrestling with where the line sits across several projects, get in touch and we can look at it with you.

Frequently asked questions

Should a ticket be marked done before it is deployed to production?

Yes, if your team treats staging as the verification environment and production deploys are batched separately. The important part is that done refers to a specific environment everyone agrees on, and that the ticket records which one. If production is the only place the feature can be checked, then done has to wait for the deploy.

How do we handle tickets that depend on another team's work?

Split them. Mark the part you control as done when your side is merged, deployed and verified against a stub or contract, and keep a separate blocked ticket for the integration. A single ticket that waits on two teams will sit in progress for weeks and distort your sprint numbers.

Is a written definition of done worth the effort for a small team?

For two or three developers who sit together, a short checklist in the ticket template is usually enough. The value grows with team size and with how many people touch the same codebase. Write the smallest version that removes the recurring argument, and extend it only when a specific problem shows up.

#Engineering