AoAD2 Practice: “Done Done”

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 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”

Whole Team

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

“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.”

Production-Ready Software

A completed story is ready to release.

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 “Key Idea: Minimize Work in Progress” describes. When your stories are done, 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?” That 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:

  • Tested (all unit and integration tests finished)

  • 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 (customers have reviewed the story and confirmed that it meets their expectations)

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

  • Accepted (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 non-functional criteria to this list, 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 non-functional requirements with dedicated stories. A compromise I learned from Bill Wake is to check expectations as part of your “done done” checklist, but not act on them. Like this: “Create a performance story if response time is more than 500ms.”

How to Be “Done Done”

Make a little progress on every aspect of your work every day.

Agile works best when you make a little progress on every aspect of your work every day, rather than working in phases or reserving the last few days of your iteration for getting stories “done done.” This is an easier way to work, once you get used to it, and it reduces the risk of having unfinished work at the end of the iteration. However, it does rely on some Delivering zone practices.

Test-Driven Development
Continuous Integration
Zero Friction

Programmers, use test-driven development to combine testing, coding, and designing. As you work, integrate with the rest of the team’s work by using continuous integration. Incrementally improve your build and deployment automation with every task that needs it. Create tasks for database migration, when appropriate, and work on them as part of each story.

Just as importantly, include your on-site customers. When you work on a UI task, show an on-site customer your progress, even if the UI doesn’t work yet. Customers often want to tweak a UI when they want to see it for the first time. This can lead to a surprising amount of last-minute work.

Similarly, as you finish tasks and integrate the various pieces of a story, run the code to make sure everything works together. While this shouldn’t take the place of automated testing, it’s good to do a sanity check to make sure there aren’t any surprises.

No Bugs

Throughout this process, you may find mistakes, errors, or outright bugs. When you do, fix them right away—then improve your work habits to prevent that kind of error from occurring again.

When you believe the story is “done done,” show it to your on-site customers for final review and acceptance. Because you reviewed your progress with them throughout the iteration, this should only take a few minutes.

Making Time

Your team should finish 4-10 stories every week. Getting that many stories “done done” may seem like an impossibly large amount of work. Part of the trick is to work incrementally, as just described, rather than in phases. The real secret, though, is to create small stories.

Many teams new to Agile create stories that are too large to get “done done.” They finish coding, but they don’t have enough time to finish everything. The UI is a little off, the tests are incomplete, and bugs sneak through the cracks.

Remember, you own your schedule.

Remember, you own your schedule. You decide how many stories to sign up for and how big they are. If your stories are too big, make them smaller! (See the “Splitting and Combining Stories” section.)


Creating large stories is a natural mistake, but some teams compound the problem by thinking, “Well, we really did finish the story, except for that one little bug.” They count it towards their capacity, which just perpetuates the problem.

Stories that aren’t “done done” don’t count toward your capacity. Even if a story only has a few minor UI bugs, or you finished everything except the last few automated tests, it counts as a zero when calculating your capacity. This will lower your capacity, giving you more time, so you can finish everything next time.

You may find that this lowers your capacity so much that you can only finish one or two stories per week. This means that your stories were too large to begin with. Split the stories you have and work on making future stories smaller.

Teams using continuous flow rather than iterations don’t track capacity, but the same idea applies. You should start and finish 4-10 stories in a single week, and each one should be “done done.” If they aren’t, make your stories smaller.


What if a story isn’t “done done” at the end of an iteration?

You’ll either try again later or make a new story for what’s left. See the “Incomplete Stories” section.


Whole Team
Team Room
Test-Driven Development
Evolutionary Design

Getting stories “done done” requires a whole team—one that includes customers, at a minimum, and possibly also testers, operations, technical writers, and more. The team needs to share a team room, either physical or virtual. Otherwise, the team is likely to have too many hand-off delays to finish stories quickly.

You’re also likely to need test-driven development and evolutionary design in order to test, code, and design each story in such a short timeframe.


When your stories are “done done:”

  • You avoid unexpected batches of work.

  • Teams using iterations spread wrap-up and polish work throughout the iteration.

  • On-site customers and testers have a steady workload.

  • The final customer acceptance review only takes a few minutes.

  • When you demonstrate your stories to stakeholders, they work to their satisfaction.

Alternatives and Experiments

This practice is the cornerstone of Agile planning. If you aren’t “done done” after every story or iteration, your capacity and forecasting will be unreliable. You won’t be able to release at will. This will disrupt your release planning and prevent you from making and meeting commitments, which will in turn damage stakeholder trust. That’s likely to lead to increased stress and pressure on the team, hurt team morale, and damage the team’s capacity for energized work.

The alternative to being “done done” is to fill the end of your schedule with make-up work. You will end up with an indeterminate amount of work to fix bugs, polish the UI, migrate data, and so forth. Although many teams operate this way, it will damage your credibility and ability to deliver. I don’t recommend it.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, 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.