James Shore

in 99 words

A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it's complete.

To achieve this result, make progress on everything each day. Use test-driven development to combine testing, coding, and design. Keep the build up to date and integrate continuously. Demonstrate progress to your customers and incorporate their feedback as you go.

Inside The Book

• "Done Done"
• Production-Ready Software
• How to Be "Done Done"
• Making Time
• Questions
  • How does testers' work fit into "done done"?
  • What if we release a story we think is "done done," but then we find a bug or stakeholders tell us they want changes?
• Results
• Contraindications
• Alternatives

Commentary

In the "Alternatives" section of this practice, Shane and I wrote:

This practice is the cornerstone of XP planning. If you aren't "done done" at every iteration, your velocity will be unreliable. You won't be able to ship at any time. This will disrupt your release planning and prevent you from meeting your commitments, which will in turn damage stakeholder trust. It will probably lead to increased stress and pressure on the team, hurt team morale, and damage the team's capacity for energized work.

There's a lot of truth in this little paragraph. Many teams I know have exactly these problems: they can only ship after several days (or weeks!) of Herculean effort; they're unable to meet release commitments; stakeholders don't trust them; and of course the team is under constant stress and pressure.

"Done done" is at the root of all of these problems. Once you complete a story, from end to end, you can tell how long a story really takes. Once you can do that, you can start making reliable estimates. (They won't be accurate, but they'll be consistent, and that's good enough.) Once you can make reliable estimates, you can make and meet iteration commitments. Once you can make and meet iteration commitments, you start building stakeholder trust. Once you build stakeholder trust, you can start negotiating scope. Once you can negotiate scope, you can make and meet release commitments. Once you can make and meet release commitments, you build trust even further, and that relieves stress and pressure on the team, which increases productivity and leads to a virtuous cycle of increased trust, collaboration, productivity, and value.

So many good things from such a simple concept. And the funny part is that "done done" is really easy to do! Just stay on task until everything is done. The hard part is the political will--sacrificing the appearance of high speed in order to take care of all of the nit-picky details. (It's also hard if you don't have a cross-functional team that sits together, but that's a whole 'nother conversation.)

I'm often asked where to start with agile development. If you have trouble making and meeting commitments, this is a good place.