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 “MINIMIZE WORK IN PROGRESS” 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.
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 “Documentation”.)
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.8 Like this: “Check response time. If >500 ms, optimize or create performance story.”
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.
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.
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, involve 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 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.
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.
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. 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” 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 toward their capacity, which just perpetuates the problem.
Stories that aren’t “done done” don’t count toward your capacity. Even if a story has only 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 finish only 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.
Your team may not have the ability to release stories on its own.9 Although the Agile ideal is cross-functional teams that have all the skills and authority needed to complete their work, as described in Chapter 4, that isn’t always possible.
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”. For example, if your legal department has to approve text, create the text and get their approval before starting the story that needs it.
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 include only the parts that are under your 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”.
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 a 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.
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 to test, code, and design each story in such a short time frame.
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.