AoAD2 Practice: “Done Done”

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

“Done Done”

Audience
Whole Team

We’re done when we’re production-ready.

Wouldn’t be nice if, once you finished a story, you never had to come back to it? That’s the idea behind “done done.” A completed story isn’t a lump of unintegrated, untested code. It’s ready to go. When the other stories planned for your current release are done, you can release without doing any further work.

Partially finished stories increase your work in progress, and this increases your costs, as the “Key Idea: Minimize Work in Progress” sidebar describes. Rather than pushing a button to release, you have to complete an unpredictable amount of work. This destabilizes your release plans and prevents you from making and meeting commitments.

Ally
Task Planning

To avoid this problem, make sure your stories are “done done.” If you’re using iteration-based task planning, all the stories in the iteration should be done at the end of each iteration. If you’re using continuous flow, stories should be done before you take them off the board. You should have the technical ability to release every completed story, even if you don’t actually do so.

What does it take for a story to be “done done”? It depends on your organization. Create a definition of done that shows your team’s story completion criteria. I write mine on the task planning board. Here’s an example:

  • Tested (all automated tests written and passing)

  • Coded (all code written)

  • Designed (code refactored to the team’s satisfaction)

  • Integrated (the story works from end to end—typically, UI to database—and fits into the rest of the software)

  • Builds (the build script works with the changes)

  • Deploys (the deploy script deploys the changes)

  • Migrates (the deploy script updates database schema and migrates data, when needed)

  • Reviewed (on-site customers have confirmed that the updated software meets their expectations)

  • Fixed (all known bugs have been fixed or scheduled as their own stories)

  • Accepted (on-site customers agree that the story is finished)

Some teams add “Documented” to this list, meaning that the story has documentation, help text, and meets any other documentation standards. (See the “Documentation” section.)

Other teams include nonfunctional criteria, such as performance or scalability expectations. This can lead to premature optimization, or difficulty getting stories done, so I prefer to plan these sorts of nonfunctional requirements with dedicated stories. A compromise is to check expectations as part of your “done done” checklist, but not necessarily act on them.1 Like this: “Check response time. If >500 ms, optimize or create performance story.”

1Thanks to Bill Wake for this suggestion.

Ally
Retrospectives

Over time, you’ll learn new things about what your software needs and improve your approach to development. For example, you might start with a “manually tested” item in your definition of done. As your approach to testing improves, you might add “automated tests written and passing” and eventually remove the “manually tested” entry. The retrospective is a good time to consider changes to the definition of done.

...to continue reading, buy the book!

In this Section

  1. “Done Done”
    1. Cargo Cult: Some Done
    2. How to Be “Done Done”
    3. Making Time
    4. Organizational Constraints
    5. Questions
    6. Prerequisites
    7. Indicators
    8. Alternatives and Experiments

Discuss the book on the AoAD2 mailing list or Discord server. For videos and interviews regarding the book, see the book club archive.

For more excerpts from the book, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.