How Shifting the Definition of Done Boosts Agile Team Throughput

Background

The Definition of Done (DoD) is an agreement within a feature team about the level of completion required for a story before it can be considered finished at the end of an iteration. When stories are large and span multiple iterations, a clear DoD helps the team align on expectations.

In agile practice, development consists of several stages, so DoD can be defined based on those stages. The author describes building a DoD process from scratch during an agile transformation and gradually moving it rightward to foster a focus‑on‑goal mindset.

Current Situation

When a DoD is defined, any work not covered by the DoD is called undone . For example, if DoD ends at testing, undone includes demonstration and release tasks. Ideally, DoD would be at release, leaving no undone work.

The team in the case study was in an early agile transformation stage, using a coarse‑grained iteration process. Team members tended to claim all stories in the iteration planning meeting, and the Product Owner would step back once stories were claimed.

Although the backlog should be sized to the team’s capacity, the reality was that many stories were started simultaneously, leading to a chaotic board where work was scattered across design and coding phases.

This resulted in a phenomenon where the first week of a three‑week iteration had almost no stories in testing, but by the third week the board was flooded with testing tasks while developers had already moved on. Only a few stories were delivered on time, and many carried over, reducing the team’s effective capacity and eroding confidence.

Introducing DoD to Regain Focus

The immediate remedy was to re‑establish confidence by setting a DoD for each story during iteration planning. The team continued to claim all stories at once, but now each story’s target for the iteration was explicitly stated.

At the end of the iteration, the team celebrated the number of stories that achieved the DoD, gradually restoring a sense of rhythm.

Iteration Completion Rate = (Number of stories that met DoD ÷ Number of planned stories) × 100%

Shifting DoD Rightward to Increase Throughput

Measuring only DoD completion does not guarantee business value because stories may still be half‑finished. The true agile goal is to deliver usable stories to users at the end of each iteration, freeing the backlog for the next cycle.

Therefore, the team raised the DoD to the release stage, eliminating undone work that would otherwise flow into the next iteration. This increased the usable capacity for planning and kept the team agile.

Iteration Delivery Rate = (Number of stories released ÷ Number of planned stories) × 100%

Note: This differs from the Completion Rate by excluding any leftover undone work.

Effect Evaluation

By moving the DoD rightward, the team began to fill the iteration backlog with stories that could realistically be completed and released within the iteration. This reduced the number of concurrent stories, clarified responsibilities, and encouraged proactive problem solving.

Consequently, the amount of undone work at the end of an iteration decreased, improving the delivery rate. Fewer carried‑over stories left more capacity for new demand in the next iteration, satisfying upstream business needs for higher throughput.

Practical Recommendations

Teams often start with a chaotic DoD. As maturity grows, evaluate opportunities to shift the DoD rightward. A typical progression:

Stage 0: No unified DoD.

Stage 1: DoD = complete testing.

Stage 2: DoD = complete demonstration.

Stage 3: DoD = complete release.

Key points to watch:

Maintain a single, team‑wide DoD to reduce cognitive load caused by differing definitions.

Ensure the DoD includes testing at a minimum, because testing bottlenecks are common.

Three typical scenarios and suggested actions:

Case 1: Stories are too large for a single iteration. Suggestion: Use story mapping to break epics into smaller stories that can be delivered independently.

Case 2: Business requires multiple stories to be released together. Suggestion: Set DoD to "demo completed" (i.e., ready for release) and coordinate a joint delivery when all related stories meet the DoD.

Case 3: After splitting stories, regression effort spikes and testing costs rise. Suggestion: Initially set DoD to functional test completion, then perform a unified regression test before release, or invest in test automation to lower regression cost and enable further DoD rightward movement.

In summary, clarifying and progressively moving the DoD helps feature teams complete agile transformations; the closer the DoD is to the user, the higher the team’s maturity and agility.