Shared Definition of Done¶
Definition¶
Scrum calls for a cross-functional team to deliver an increment of the product to a state of "potentially releasable" every sprint. This is not the same as "developers finished coding, testers will test it next sprint" (a pattern called scrummerfalls, mini-waterfall cycles squeezed into iterations). True done means the feature is tested, documented, integrated, and ready to ship within the sprint.
Done is a whole-team responsibility, not a quality gate owned by testers or operations. The team's definition of done evolves as the team matures. A newly formed team may start with a less stringent definition while learning to work in new ways. But great ScrumMasters understand when to be pragmatic and when to push forward, moving the team toward delivering truly releasable increments sprint after sprint.
In the Book¶
Watts tells the story of the Doomsday Bunnies, a newly formed cross-functional team of 10 (developers, testers, architect, UX lead) delivering a financial transaction monitoring system with a projected ROI of $16M in the first six months.
In Sprint 1, the team committed to eight items but completed only three. Developers and testers weren't synchronized. Developers finished coding and handed work off to testers; with limited testing bandwidth, features piled up. The testers complained the developers weren't concerned about quality. The developers complained they could have coded more if they weren't stuck fixing bugs.
At the retrospective, the team suggested splitting into two teams: developers in one (working on new features), testers in another (testing last sprint's work). This would give developers a "headstart." Stevie, the ScrumMaster, asked: "Is an item truly done if it's not tested?"
The team reluctantly admitted no, but they felt stuck. Stevie then reframed: "What if we stop thinking of testing as an activity to find defects and more as an activity to prevent defects?" Could they work as one team to get items to a potentially shippable state within one sprint?
The team generated options: pairing developers with testers during coding (so testing feedback shapes the code as it's written); turning acceptance criteria into test scripts before coding starts, so testers can write tests while developers code; setting kanban WIP limits on testing and swarming when the limit is hit.
They tried pairing developers with testers. It worked. The team learned to collaborate instead of hand off. Quality improved. Velocity stabilized.
Watts emphasizes that scrummerfalls—the mini-waterfall pattern—are a trap. Almost all new teams fall into it. Great ScrumMasters spot it early and help teams understand that "done" is not a stage gate but a shared definition that only the team can own and enforce.
Why It Matters¶
When done is a handoff (developers to testers to ops), you optimize each stage independently, which fragments accountability and slows overall flow. When done is shared, the team self-organizes to avoid bottlenecks because the whole team is responsible for the outcome. The definition of done becomes a forcing function that surfaces organizational issues (skills gaps, tool gaps, dependencies) that must be addressed to succeed. This framing applies anywhere work moves through multiple functions; shared ownership of completion beats function-level optimization.