• Next: No Bugs
• Previous: Chapter 7: Releasing
• Up: Chapter 7: Releasing

in 99 words

A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it's complete.

To achieve this result, make progress on everything each day. Use test-driven development to combine testing, coding, and design. Keep the build up to date and integrate continuously. Demonstrate progress to your customers and incorporate their feedback as you go.

Commentary

The Cornerstone of Agile Planning

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

"Done Done"

Audience

Whole Team

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

"Hey, Liz!" Rebecca sticks her head into Liz's office. "Did you finish that new feature yet?"

Liz 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 around to look at Rebecca. "It only took me half a day, too."

"Wow, that's impressive," says Rebecca. "We figured it would take at least a day, probably two. Can I look at it now?"

"Well, not quite," says Liz. "I haven't integrated the new code yet."

"Okay," Rebecca 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 precisely because of this feature. I'm going to install the new build on their test bed so they can play with it."

Liz frowns. "Well, I wouldn't show it to anybody. I haven't tested it yet. And you can't install it anywhere—I haven't updated the installer or the database schema generator."

"I don't understand," Rebecca says irritably. "I thought you said you were done!"

"I am," insists Liz. "I finished coding just as you walked in. Here, I'll show you."

"No, no, I don't need to see the code," Rebecca says. "I need to be able to show this to our customers. I need it to be finished. Really finished."

"Well, why didn't you say so?" says Liz. "This feature is done—all coded up. It's just not done done. Give me a few more days."

Production-Ready Software

You should able to deploy the software at the end of any iteration.

Wouldn't it 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 deploy.

Partially-finished stories result in hidden costs to your project. When it's time to release, you have to complete an unpredictable amount of work. This destabilizes your release planning efforts and prevents you from meeting your commitments.

To avoid this problem, make sure all of your planned stories are "done done" at the end of each iteration. You should be able to deploy the software at the end of any iteration, although normally you'll wait until more features have been developed.

What does it take for software to be "done done"? That depends on your organization. I often explain that a story is only complete when the customers can use it as they intended. Create a checklist that shows the story completion criteria. I write mine on the iteration planning board:

• Tested (all unit, integration, and customer 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 includes any new modules)

• Installs (the build script includes the story in the automated installer)

• Migrates (the build script updates database schema if necessary; the installer migrates data when appropriate)

• 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)

Ally

The XP Team

Some teams add "Documented" to this list, meaning that the story has documentation and help text. This is most appropriate when you have a technical writer as part of your team.

Other teams include "Performance" and "Scalability" in their "done done" list, but these can lead to premature optimization. I prefer to schedule performance, scalability, and similar issues with dedicated stories (see Performance Optimization in Chapter 9).

How to Be "Done Done"

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

XP works best when you make a little progress on every aspect of your work every day, rather than 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 finding unfinished work at the end of the iteration.

Allies

Test-Driven Development

Continuous Integration

Ten-Minute Build

Use test-driven development to combine testing, coding, and designing. When working on an engineering task, make sure it integrates with the existing code. Use continuous integration and keep the ten-minute build up to date. Create an engineering task (see Iteration Planning in Chapter 9) for updating the installer and have one pair work on it in parallel with the other tasks for the story.

Just as importantly, include your on-site customers in your work. As you work on a UI task, show a customer what the screen will look like, even if it doesn't work yet (see Incremental Requirements in Chapter 9). 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 if you delay any demos to the end of the iteration.

Ally

Exploratory Testing

Similarly, as you integrate various pieces, run the software to make sure they all work together. While this shouldn't take the place of testing, it's a good check to help prevent you from missing anything. Enlist the help of the testers on occasion and ask them to show you exploratory testing techniques. (Again, this review doesn't replace real exploratory testing.)

Ally

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 customers for final acceptance review. Because you reviewed your progress with customers throughout the iteration, this should only take a few minutes.

Making Time

This may seem like an impossibly large amount of work to do in just one week. It's easier to do if you work on it throughout the iteration rather than saving it up for the last day or two. The real secret, though, is to make your stories small enough that you can completely finish them all in a single week.

Many teams new to XP create stories that are too large to get "done done." They finish all of the coding, but they don't have enough time to completely finish the story—perhaps the UI is a little off, or a bug snuck through the cracks.

Remember, you are in control of your schedule. You decide how many stories to sign up for and how big they are. Make any story smaller by splitting it into multiple parts (see Stories in Chapter 8) and only working on one of the pieces this iteration.

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 give themselves credit for the story, which inflates their velocity and perpetuates the problem.

If a story isn't "done done", don't count it towards your velocity.

If you have trouble getting your stories "done done," don't count those stories towards your velocity (see Estimating in Chapter 8). Even if the story only has a few minor UI bugs, count it as a zero when calculating your velocity. This will lower your velocity, which will help you choose a more manageable amount of work in your next iteration.

You may find that this lowers your velocity so much that you can only schedule one or two stories in an iteration. That means that your stories were too large to begin with. Split the stories you have and work on making future stories smaller.

Questions

How does testers' work fit into "done done"?

Ally

Exploratory Testing

In addition to helping customers and programmers, testers are responsible for nonfunctional testing and exploratory testing. Typically, they do these only after stories are "done done". They may perform some non-functional tests, however, in the context of a specific performance story.

Regardless, the testers are part of the team, and everyone on the team is responsible for helping the team meet its commitment to deliver "done done" stories at the end of the iteration. Practically speaking, this usually means that testers help customers with customer testing, and they may help programmers and customers review the work in progress.

What if we release a story that we think is "done done," but then we find a bug or stakeholders tell us they want changes?

Ally

Slack

If you can absorb the change with your slack, go ahead and make the change. Turn larger changes into new stories.

Ally

Release Planning

This sort of feedback is normal—expect it. The product manager should decide whether the changes are appropriate, and if they are, he should modify the release plan. If you are constantly surprised by stakeholder changes, consider whether your on-site customers truly reflect your stakeholder community.

Results

When your stories are "done done," you avoid unexpected batches of work and spread wrap-up and polish work throughout the iteration. Customers and testers have a steady workload through the entire iteration. The final customer acceptance demonstration takes only a few minutes. At the end of each iteration, your software is ready to demonstrate to stakeholders with the scheduled stories working to their satisfaction.

Contraindications

Allies

Iteration Planning

Stories

The XP Team

Sit Together

Incremental Design And Architecture

Test-Driven Development

This practice may seem advanced. It's not, but it does require self-discipline. To be "done done" every week, you must also work in iterations and use small, customer-centric stories.

In addition, you need a whole team—one that includes customers and testers (and perhaps a technical writer as well) in addition to programmers. The whole team must sit together. If they don't, the programmers won't be able to get the feedback they need in order to finish the stories in time.

Finally, you need incremental design and architecture and test-driven development in order to test, code, and design each story in such a short timeframe.

Alternatives

Allies

Release Planning

Trust

Energized Work

This practice is the cornerstone of XP planning. If you aren't "done done" at every iteration, your velocity will be unreliable. You won't be able to ship at any time. This will disrupt your release planning and prevent you from meeting your commitments, which will in turn damage stakeholder trust. It will probably 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, create an installer, and so forth. Although many teams operate this way, it will damage your credibility and your ability to deliver. I don't recommend it.

• Next: No Bugs
• Previous: Chapter 7: Releasing
• Up: Chapter 7: Releasing