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.
- Whole Team
We’re done when we’re production-ready.
Cargo Cult: Some Done
“Hey, Valentina!” Shirley sticks her head into Valentina’s office. “Did you finish that new feature yet?”
Valentina nods. “Hold on a sec,” she says, without pausing in her typing. A flurry of keystrokes crescendos and then ends with a flourish. “Done!” She swivels triumphantly to look at Shirley. “It only took me half a day, too.”
“That’s impressive,” says Shirley. “We figured it would take at least a day, probably two. Can I look at it now?”
“Well, not quite,” says Valentina. “I haven’t integrated the new code yet.”
“Okay,” Shirley says. “But once you do that, I can look at it, right? I’m eager to show it to our new clients. They picked us specifically for this feature. I’m going to deploy the new build on their test bed so they can play with it.”
Valentina frowns. “Well, I wouldn’t show it to anybody yet. I haven’t tested it. And you can’t deploy it anywhere—I haven’t updated the deploy script or the migration tool.”
“I don’t understand,” Shirley grumbles. “I thought you said you were done!”
“I am,” insists Valentina. “I finished coding it just as you walked in. Here, I’ll show you.”
“No, no, I don’t need to see the code,” Shirley replies. “I need to show this to our customers. I need it to be finished. Really finished.”
“Well, why didn’t you say so?” says Valentina. “This feature is done—it’s all coded up. It’s just not done done. Give me a few more days.”
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.
- 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.
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
- “Done Done”
- Cargo Cult: Some Done
- How to Be “Done Done”
- Making Time
- Organizational Constraints
- Alternatives and Experiments