Effective agile teams get things done. They build software day after day that’s not just “code complete” but really shippable. And when their product owner says, “ship it,” they can get their shippable software into production at the drop of a hat.

The Definition of Done can be a powerful tool to make these things happen…If it’s used right.

Most agile teams I see have one of four relationships with a Definition of Done:

1. They don’t have one
2. They have one but don’t really use it
3. They have one but can never satisfy it
4. They have one, satisfy it for each story, but still have lots to do at the end of a release

I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint.

The reason why, I think, is that if a team uses a Definition of Done at all, they try to use a single one before they’re ready. I’ve discovered that most teams really need two definitions of done. For a new agile team, there’s more to do to get software ready for production than can be accomplished a story at a time. Teams that fall into #3 above probably put everything on the Definition of Done. Teams in #4 probably put just those things they could do a story at a time on the Definition of Done and left everything else for later.

The answer is two Definitions of Done. The Story Definition of Done captures what the team can do today to make each story as shippable as possible in each sprint. The Release Definition of Done captures the gap between the Story Definition of Done and what’s actually required to ship. Together these tools provide a way to visualize what done means and to make it happen as early as possible.

Here’s how to build effective Story and Release Definitions of Done…

Building The Two Definitions of Done

1. Brainstorm the List

List all the things required to move a set of features in your product to production. Engage release management, operations, help desk, and other stakeholders at this point—it’s easier to build what they need into the software than to bolt it on at the end. This list typically includes things like:

• user documentation
• operations documentation
• monitoring and logging
• performance testing
• regression tested in a clean QA environment

Now, list anything required to deliver software at a consistently fast pace from iteration to iteration. For example:

• automated unit tests covering 80% of code
• automated story tests covering 90% of acceptance criteria
• adherence to coding standards
• code reviewed by another developer
• all production code developed by a pair

Finally, list non-functional requirements such as:

• all pages load in under a second
• all pages can support 300 simultaneous user sessions

Merge these lists into one, changing the language where necessary so that each bullet reads as a continuation of the sentence beginning: “In order for a set of features to be released to production…”

2. Challenge the List

For each item on the list, ask “why?” Keep asking “why?” until it’s clear that the item is the simplest, cheapest, most repeatable way to achieve some desired goal in the release. If it’s not, change it.

This is where you challenge the existing rules around releases. Maybe your release readiness guidelines today require a complete installation guide. Could you replace that with an automated installation script?

3. Build Release Readiness In

Now you have a list of the minimal set of things a group of features must have to be released—your Release Definition of Done. Bolting those things onto an otherwise complete set of features could impose a fixed cost of weeks to the end of any release. One of our goals in agile is to allow the product owner to be able to say at any point, “This is enough, I want to start making money off of this software now—ship it.” An expensive release gets in the way.

Look at each item on the list and ask, “Could we satisfy this as we build each story instead of all at once at the end of a release?” Yes? Then move it to your Story Definition of Done. No? Could you do part of it or do something that would reduce the time at the end? Yes? Then put that on your Story Definition of Done. No? Then leave it on the Release Definition of Done.

Very few items can’t be satisfied a story at a time. The most common ones I see are performance testing in a production-like environment shared with other products and beta testing with a set of real users. But you can get a head start on even these. Maybe your test environment isn’t exactly like production, but can you make the performance constraints similar enough to at least profile for likely performance issues? Maybe you can’t beta test on a large scale, but could you get a small set of users to volunteer to use stories as they’re built and provide early feedback to make the beta test shorter and more predictable? Think hard about anything you’re tempted to leave on the Release Definition of Done.

4. Use Your Definitions of Done

You now have two definitions of done, one for every story you build and one for a collection of stories you want to release. The Story Definition of Done will inform your acceptance criteria for every story. If page load time matters, a story isn’t done until all the related pages load fast enough. Test for this. Automate these tests and run them on every build if you can.

You won’t satisfy the items on your Release Definition of Done until the end of a release. But this doesn’t mean you can forget about them until then. Keep the Release Definition of Done visible, and look for ways to test early for release readiness.

5. Grow Your Story Definition of Done

The Definitions of Done are a starting place, a statement of what your team can accomplish today. Over time, your Release Definition of Done should get smaller and your Story Definition of Done should grow. If you have 3 weeks of manual regression testing at the end of each release, come up with a plan to grow automated regression tests as you build new stories. Maybe you can reduce those 3 weeks of testing to one. If you have a tech writer spend a month writing documentation at the end of a release today, find ways to integrate her into the team to grow the documentation as you grow the software. Maybe you can reduce that month of writing to 3 days of editing and polishing.

The Bottom Line

Use two definitions of done. In every retrospective, look for ways to grow your Story Definition of Done so you can consistently build and release software quickly. If you get to a point where you can throw away the Release Definition of Done, congratulations! But don’t start there.

Related posts:

1. Web Testing for .NET Teams: WatiN or Watir?
2. Surviving Rewrites
3. Free Agile Product Management Seminar – Nov 11, Denver

I’ve written before about the amazing financial impact of releasing more often. And I know from personal experience the positive impact that frequent releases have on learning and on product quality and value. So, I enjoyed this post on one company’s experience with continuous releases. Yes, you read that right; they release, on average, 50 times per day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

Read the whole thing and consider what it would take in your organization to get to continuous deployment. How fast could you go? And what impediments would have to be resolved to make it happen?

Related posts:

1. Continuous Integration and the Bad Head Problem
2. Continuous Integration in Under an Hour
3. One Word Can Change Your Daily Scrum

As the saying goes, “Cash is king.” It doesn’t matter how good your P&L or balance sheet looks or how good the business case for your project is, if you don’t have enough cash every month to pay the bills, you won’t stay in business.

With the economy tightening, then, companies are desperately trying to cut costs in order to stay cash flow positive. In IT the major cost is salary, so cutting costs means cutting people. Nobody likes that.

Fortunately, there’s a simple way to reduce expenses and increase returns on a software project: incremental releases.

A Typical Big Bang Release

Let’s look at a example. Our project will spend $1m (mostly salaries) for a year of development starting in January 2009, release at the end of that year, and is projected to make $2m over its first year in production. We’ll simplify this model and assume that expenses and returns will be distributed evenly over their respective years. We’ll ignore ramp up time and we won’t discount future cash.

The result is a cumulative cash flow chart that looks like this:

We spend money linearly until we’ve spent our whole million. Then, we release the software and start making money linearly until we make the projected two million. We break even in June of 2010, 18 months in, and we see a 100% ROI.

Variation 1: Incremental Releases

Now, let’s keep all those same assumptions and make one small change. Instead of building the software and releasing it all at once, let’s break it into four equal size feature sets. Every three months we’ll build and release one until the whole product is released. To simplify things again, we’ll assume that each feature set is equally valuable and will account for a quarter of the expected return. Since we can start seeing returns as soon as we release a feature set, our cumulative cash flow now looks like this:

With this arrangement, we only need to invest $375k in the project rather than $1m. We break even in February 2010, 14 months in. With an investment of $375k for $1.75m in returns ($2.75m in revenue less the same $1m in expenses as the previous example) we see a 467% ROI over two years.

Variation 2: Prioritizing Releases by Value

For most projects, however, value isn’t distributed evenly across the features. Usually an 80/20 rule applies and some features are much more valuable than others. For our hypothetical project, let’s assume that we can divide up our features to get a pretty typical distribution where Feature Set A accounts for 50% of the value, Feature Set B for 30%, Feature Set C for 12%, and Feature Set D for 8%. Now, our cumulative cash flow looks like this:

When we deliver feature increments by value, we have to invest only $250k for a $2.1m return, or 844% ROI. We break even in November 2009, before the original project was even going to release!

Variation 3: Cutting Out Low-Value Releases

Once we’ve prioritized our features by value, we can go one step further. We can decide that some features aren’t worth the investment. With their long 15 and 19 month waits to break even, feature sets C and D may not be worth it. Over the two years we’re considering, those features have a negative ROI. Let’s cut them out of the project and have the team do something else more valuable. Here’s our cumulative cash flow now:

This variation generates less revenue, but only spends half as much. The return is $2.15m on a $250k investment, or 860% ROI. It breaks even in August 2009, tying up the cash for less time and freeing the team to do something else more valuable. In fact, if we can assign the team to two feature sets on another project as valuable as A and B were on this project, our two year cumulative cash flow looks like this:

Now we see $3.5m returned on our $250k investment, an ROI of 1400%. We break even in October 2009, still three months before the original plan would have had us starting to see a return at all. Simply by rearranging our work by value and releasing incrementally, we’ve dramatically improved our cash flow situation while increasing our revenue. And we didn’t have to lay anyone off to do it. Going into a tight economy, odds are that this is exactly what your business needs.

(In case you’re interested, here are the details behind the charts: big-bang-vs-incremental-releases-cash-flow.xls.)

Related posts:

1. Surviving Rewrites
2. The Most Useful Release Burn-up I've Seen Yet
3. The Most Useful Release Burn-up I’ve Seen Yet

It seems like fully half the projects I come across are rewrites in one form or another. It ought to be common knowledge by now that rewrite projects have a very bad track record, but perhaps the bad results are connected to the inordinate attractiveness of “doing it right this time.” The chance to replace the ugly production system with a new, pure, buzzword-compliant ode to software architecture is one of the more compelling siren songs for developers. Too bad about those rocks.

Given that rewrites aren’t going away, here are the things I recommend software organizations consider to maximize their chances of avoiding the rocks (and maybe even be wildly successful!).

1. The problem isn’t as well known as you think it is. Run away from specs that say, “The new system shall do everything the old system does plus new functions X, Y, and Z.” No one knows exactly what the system does. It got to where it is today through the accretion of features, hacks, and workarounds. You’re almost guaranteed to break someone’s unofficial report when you rebuild the system “right.”
2. BDUF still doesn’t work, even if the previous version of the system already exists. Sure, you’ve architected the perfect service-oriented, social-media, domain-specific new system. Unfortunately, it’s wrong. In the end, the new system is going to look nothing like you envision. You can’t see the future any more than the previous team could. (In fact, they were probably replacing some other system and “doing it right this time.”)
3. The customer almost always wants the existing system plus something new. By now, the existing system is probably what David Anderson calls table stakes. Since the existing system exists, you’re already in the game. Don’t start by building the table stakes again. The new features are probably spoilers or differentiators. Those have real incremental business value. If the existing system works, build the new features first. Figure out a way to integrate them with the existing system as necessary. Then grow the new system to choke out the existing one. (Martin Fowler call this pattern Strangler Application.) Eventually, you’ll have your whole new system, but it’ll bring new value from day one instead of spending months or years catching up with the existing system. It’s harder to architect a system incrementally than from scratch, but architects like challenges, right?
4. Involve the business. Don’t let them send you to the existing system as a specification. Starting with the new features makes this a pretty easy sell. Someone’s excited enough about those new features to work with your team. Keep a blend of new and replacement features through the whole project and they’ll stay engaged.
5. Release early and often. Business value can only be realized if people are using the software. Moreover, the quality of the feedback you receive will be better if your software is being used by real users with real data. This is standard agile stuff and shouldn’t come as a surprise to anyone, but rewrite projects seem to have a logic of their own.

For more rewrite project advice, check out Chad Fowler’s excellent 2006 series on the topic.

What other tips would you give teams considering a rewrite project? Share them in the comments.

Related posts:

1. One Word Can Change Your Daily Scrum