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.

Revised: July 14, 2021

“Done Done”

Whole Team

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

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” on page XX 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 (customers have confirmed that the updated software 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 “Documentation” on page XX.)


Other teams include non-functional 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 non-functional 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 >500ms, 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.

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
Incident Analysis

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.

In some cases, you may discover a bug or other surprise that significantly increases the size of the story. In this case, it’s okay to work with your on-site customers to schedule the additional work as a separate story (or stories). If it’s the result of a coding or design error, schedule it immediately into the next iteration or story slot, because these types of errors tend to increase your development costs and become more expensive to fix over time.

Don’t get complacent, though: this sort of added story should be rare. If it happens more than a few times per quarter, something is wrong. If the surprises are related to missing or misunderstood requirements, focus on improving customer involvement. If they’re related to coding errors, improve Delivering fluency. If neither of those options work, ask a mentor for help.

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 development, this should only take a few minutes.

Making Time

The secret to “done done” is to create small stories.

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 which 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. You decide how many stories to sign up for and how big they are. If your stories are too big, make them smaller! “Splitting and Combining Stories” on page XX describes how.


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.

Organizational Constraints

Your team may not have the ability to release stories on their own.2 Although the Agile ideal is cross-functional teams that have all the skills and authority needed to complete their work, as described in chapter “Invest in Agility”, that isn’t always possible.

2Thanks to Bas Vodde, Thomas Owens, and Ken Pugh for their contributions to this section.

For example, your legal department might need to review the text for a story before it can be released. Your operations department might not allow you to conduct your own deployments. You might need to conduct a third-party security review, or undergo user acceptance testing.

Try to resolve as many dependencies as you can prior to starting work on a story, as described in “Cross-Team Dependencies” on page XX. For example, if your legal department has to approve text, create the text and get their approval before starting the story that needs it.

No Bugs
Customer Examples
Impediment Removal

For pre-release dependencies, such as a security review or user acceptance testing, you can define “done” as handing off the software for validation and release, rather than actually releasing. Your definition of done would only include the parts that are under you control. However, as much as possible, treat those final steps as a safety net. If they find any problems, treat them as seriously as defects found in production.

Over time, work to decrease the amount of time needed for third-party dependencies. For example, some teams use automated customer examples to streamline third-party validation. Enlist the help of your manager to change organizational requirements and bring the skills you need into your team.


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

Either try again later or make a new story for what’s left. See “Incomplete Stories” on page XX.

Why does “Tested” come before “Programmed” and “Designed” in your list? Shouldn’t we design, then program, then test?

The “done done” list isn’t an ordered list of steps or phases to follow in order; it's a final check to make sure you didn’t forget anything. Agile works best when you perform development “phases” incrementally and simultaneously rather than one at a time. Part III describes how this works.

Why don’t you have manual testing in your list?

Manual testing results in a “test and fix” phase at the end of development, which makes it difficult to finish work reliably. Part III describes how to replace a “test and fix” phase with incremental automated testing.

Remember that my list is only an example. If your team uses manual testing, has additional operations requirements, or needs to do anything else for a story to be done, include it in your list.


Whole Team
Team Room
Test-Driven Development
Incremental 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.

  • Customer acceptance only takes a few minutes.

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.