Definition
Definition of Done
A definition of done is a shared, explicit checklist of what must be true before any work item counts as complete — code reviewed, tests passing, documentation updated, deployed. It removes ambiguity about the word 'done,' preventing half-finished work from being declared finished and creating a consistent quality bar across the whole team.
Key takeaways
- A definition of done is a shared, explicit checklist of what must be true before any work item counts as complete — code reviewed, tests passing, documentation updated, deployed. It removes ambiguity about the word 'done,' preventing half-finished work from being declared finished and creating a consistent quality bar across the whole team.
- Without a definition of done, 'done' means whatever each person decides in the moment — and those meanings rarely agree.
- Planoda supports per-team workflow states and checklists, so a definition of done can be encoded as a gate issues pass through before reaching the done state.
Without a definition of done, 'done' means whatever each person decides in the moment — and those meanings rarely agree. One developer's 'done' is code written; another's includes tests, review, docs, and a production deploy. The result is work that gets marked complete and then bounces back, polluting metrics and eroding trust. A definition of done makes the standard explicit and collective.
A good definition is a short, universal checklist that applies to every item: merged to main, tests green, reviewed by a peer, no known regressions, user-facing changes documented. It is not the acceptance criteria for one specific issue — those describe what a particular feature must do — but the baseline quality gate every issue must clear regardless of what it is.
The definition should be visible and enforced, not buried in a wiki. When it lives where work is tracked, the team can treat it as a real gate: an issue cannot move to done until each box is checked. This keeps velocity and burndown honest, because 'done' actually means done.
Planoda supports per-team workflow states and checklists, so a definition of done can be encoded as a gate issues pass through before reaching the done state.
Related terms
- Story Points (Estimation)Story points are a relative, unitless measure of how much effort an issue will take, accounting for complexity and uncertainty rather than raw hours. Teams estimate in points — often using a Fibonacci-like scale — to compare items against each other quickly. Summed across a cycle, points feed velocity and burndown without false precision about clock time.
- VelocityVelocity is the average amount of work a team completes per cycle, measured in issues or story points. By tracking it over several cycles, teams forecast how much they can realistically take on next. Velocity is a planning aid for a specific team over time — never a target to maximize or a way to compare teams against each other.
- BurndownA burndown chart tracks remaining work against time over a cycle, sloping from the total scope down toward zero as items are completed. It shows whether a team is on pace to finish what it committed to, making slippage visible early. The ideal line falls steadily; a flat line warns that work is stalling.
- Cycle (Sprint)A cycle — often called a sprint — is a fixed, repeating time-box, usually one or two weeks, during which a team commits to a focused set of work and aims to finish it. Cycles create a regular cadence for planning, focus, and review, turning an open-ended backlog into shippable increments.