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

Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.

Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable.

Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories.

(Note: As with any pattern language, I didn’t invent these patterns, I’ve just observed and compiled them. For example, this great post by Lasse Koskela put names on some patterns I’d observed but not named, especially “Major Effort.”)

How Small?

How small should stories be? I recommend 6-10 stories per iteration, so how small is small enough depends on your team’s velocity. Before your next planning meeting calculate what estimate should trigger splitting a story. For most teams, it seems to be 8 or 13 points. But on a recent project I’m doing by myself, I’ve needed to split 5-point stories.

When you’re in a planning meeting and you hit your trigger estimate, pull out the cheat sheet at the end of this article and try a few of the patterns until you find a good split.

Which Pattern to Use

You’ll often find that you can split a story using several of the patterns. Which split should you choose? I use two rules of thumb:

1. Choose the split that lets you deprioritize or throw away a story. The 80/20 principle says that most of the value of a user story comes from a small share of the functionality. When one split reveals low-value functionality and another doesn’t, it suggests that the latter split hides waste inside each of the small stories. Go with the split that lets you throw away the low-value stuff.
2. Choose the split that gets you more equally sized small stories. The split that turns an 8 point story into four 2 point stories is more useful than the one that produces a 5 and a 3. It gives the Product Owner more freedom to prioritize parts of the functionality separately.

Pattern #1: Workflow Steps

Here’s a story from a content management system one of my clients was creating:

As a content manager, I can publish a news story to the corporate website.

Didn’t sound too big—until we dug into the workflow to get a story published. It turned out that just to get a few sentence news story on the corporate website required both editorial and legal approval and final review on a staging site. There’s no way 6-10 stories like this would fit in an iteration.

In a workflow like this, the biggest value often comes from the beginning and end. The middle steps add incremental value, but don’t stand alone. So it can work well to build the simple end-to-end case first and then add the middle steps and special cases.

The new stories included:

…I can publish a news story directly to the corporate website.
…I can publish a news story with editor review.
…I can publish a news story with legal review.
…I can view a news story on a staging site.
…I can publish a news story from the staging site to production.

Pattern #2: Business Rule Variations

This story has a few equally complex stories hidden within it that accomplish the same thing using different business rules:

As a user, I can search for flights with flexible dates.

Digging into “flexible dates” reveals several different business rules, each of which can be a good story on its own:

…as “n days between x and y.”
…as “a weekend in December.”
…as “± n days of x and y.”

Pattern #3: Major Effort

Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one. For example, this credit card processing story,

As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express.

could be split into four stories, one for each card type. But the credit card processing infrastructure will be built to the support the first story; adding more card types will be relatively trivial. We could estimate the first story larger than the other three, but then we have to remember to change our estimates if the Product Owner later changes priorities. Instead, we should defer the decision about which card type gets implemented first like this:

…I can pay with one credit card type (of VISA, MC, DC, AMEX).
…I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).

The two new stories still aren’t independent, but the dependency is much clearer than it would be with a story for each card type.

Pattern #4: Simple/Complex

When you’re in a planning meeting discussing a story, and the story seems to be getting larger and larger (“what about x?”; “have you considered y?”), stop and ask, “What’s the simplest version of this?” Capture that simple version as its own story. You’ll probably have to define some acceptance criteria on the spot to keep it simple. Then, break out all the variations and complexities into their own stories. So, for example, this story,

As a user, I can search for flights between two destinations.

stays simple by splitting off variations like,

…specifying a max number of stops.
…including nearby airports.
…using flexible dates.
…etc.

Pattern #5: Variations in Data

Complexity in a story can come from handling variations in data. For example, a system I’m currently working on needs to model geographic areas served by transportation providers. We could have burned our whole project budget just handing geography; it’s potentially that complex. When I talked through the story,

As a user, I can search for transportation providers by trip origin and destination.

with our Product Owner, I discovered that, while we didn’t need full-fledged GIS, modeling geography would still be quite complex. We stopped and asked, “What’s the ‘good enough’ way to model geography so we can build other high-value features now?” We settled on,

As a user, I can search for transportation providers by trip origin and destination as counties.

This worked for a while, until we collected more data and found that some providers only served certain cities or even neighborhoods. So a new story came up:

As a user, I can search for transportation providers by trip origin and destination as counties, cities, towns, or neighborhoods.

Looking over the new provider data, we also discovered that some providers will support trips originating in a single city but ending in any number of surrounding cities. This led to the story:

Providers can serve different geographic areas for trip origin and destination.

All three of these stories are split from the original geography story. The difference here is that we added stories just-in-time after building the simplest version. But sometimes you know the data variations up-front. The classic example is localization:

As a content manager, I can create news stories.
…in English.
…in Japanese.
…in Arabic.
…etc.

Pattern #6: Data Entry Methods

Complexity sometimes is in the user interface rather than in the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI. These, of course, aren’t independent—the second story effectively is the original story if you do it first—but it still can be a useful split.

As a user, I can search for flights between two destinations.
…using simple date input.
…with a fancy calendar UI.

Pattern #7: Defer Performance

Sometimes, a large part of the effort is in making a feature fast—the initial implementation isn’t all that hard. But you can learn a lot from the slow implementation and it has some value to a user who wouldn’t otherwise be able to do the action in the story. In this case, break the story into “make it work” and “make it fast”:

As a user, I can search for flights between two destinations.
…(slow—just get it done, show a “searching” animation).
…(in under 5 seconds).

Pattern #8: Operations (e.g. CRUD)

The word “manage” in a user story is a giveaway that the story covers multiple operations. This offers a natural way to split the story. For example:

As a user, I can manage my account.
…I can sign up for an account.
…I can edit my account settings.
…I can cancel my account.

Pattern #9: Break Out a Spike

A story may be large not because it’s necessarily complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. Then, you can do the implementation or have a better idea of how to break it up. Don’t know how to implement the following story?

As a user, I can pay by credit card.

Then, break it into:

Investigate credit card processing.
Implement credit card processing.

In the “investigate” story, the acceptance criteria should be questions you need answered. Do just enough investigation to answer the questions and stop; it’s easy to get carried away doing research.

The spike split is last because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.

Conclusion

Resist the temptation to split an overly large user story by architectural layers. Instead, try these patterns to split your story into smaller stories that still satisfy the INVEST model. Let me know how it works for you or if you’ve run into unsplittable stories (I love a challenge!).

Download the Story Splitting Cheat Sheet

Related posts:

1. Short Answers #1: When Stories Are Larger Than Planned
2. WatiN Patterns #2: One Assertion and a Name to Match
3. Agile Product Management Boot Camp

Update: If you’ve just landed here, you could get the impression from this post that Cuke4Nuke doesn’t exist yet. It does. Check out this screencast showing what you can do with it as of early December 2009.

If you’ve read this blog for a while or talked with me about functional test tools, you’ve heard me talk about Cucumber. It’s my favorite ATDD tool because it’s so good at mapping stories and acceptance criteria to automated functional tests. Product Owners and BAs write acceptance criteria in natural language. Developers and testers unobtrusively automate tests for them. Anyone on the team can run the tests and see the current state of the system.

Here’s a simple example:

This reads almost exactly as I teach Product Owners to specify acceptance criteria. But it’s not just text. It’s a potentially automated test.

A developer or tester can come along and automate this test like so in Ruby:

Each of the Given/When/Then calls is a step definition. When there’s a matching line in a Cucumber test, the step definition gets executed.

Recently, support was added for step definitions in Java via a project called Cuke4Duke:

Now, a Java team can use Cucumber without ever writing a line of Ruby.

Unfortunately, there’s nothing like this for .NET teams. Until now (or soon, anyway)…

AA-FTT and the Birth of Cuke4Nuke

Last month, I attended the Agile Alliance Functional Test Tool conference (AA-FTT for short). AA-FTT is an open space conference. I came with one goal: to get together with other people who want Cucumber for .NET and start making it happen. I wasn’t sure anyone else would be interested, so I was thrilled with the reaction.

Aslak Hellesøy introduced Cucumber for those in the group who hadn’t used it and then talked through the multiple language support he’d recently added to the tool. Then, we discussed ways to build .NET support. The obvious solution was to use IronRuby and Cucumber’s language support to handle C# step definitions. Matt Wynne downloaded the latest IronRuby and installed Cucumber on it. He kicked off a simple Cucumber example, and we waited. And waited. Some two minutes later, we had results from tests that take less than two seconds to run under the standard Ruby interpreter. In a process that values frequent, fast test runs, IronRuby was a non-starter. (If you want to try Cucumber under IronRuby, here are some instructions.)

So we discussed other options and settled on using a simple wire protocol for Cucumber to communicate to .NET out-of-process, similar to Slim in FitNesse. And here’s the best part: we started building it. Matt and I paired right there to start fleshing out the wire protocol (with Cucumber tests, naturally). Later in the week at Agile 2009, Matt and Aslak paired to build the Ruby side of the wire protocol, and Matt and I tackled the first bits of the .NET side. Last week, I got the skeleton of the .NET side working and up on GitHub. You can define simple steps in C#. Cucumber can ask the .NET wire server to tell it about the steps it has and to invoke them and return the pass/fail results.

About a week ago, Aslak announced the project on the Cucumber mailing list and recruited more contributors. Declan Whelan, Scott Ford, Åsmund Eldhuset, Anders Hammervold, Chris Kooken, and Steve Eley have already stepped up with ideas and code.

Getting Involed

How can you get involved? I’m glad you asked.

1. Join the mailing list.
2. Fork the GitHub repository and work on one of the features in the backlog.
3. Post a message to the mailing list to let us know what you’re working on. I’ll tag the ticket in the backlog with your GitHub username so we don’t duplicate effort. Prefix your message subject with [Cuke4Nuke].
4. Comment on tickets in the backlog.
5. Try using Cuke4Nuke as we develop it and give us feedback via the mailing list.
6. Shout encouragements in the comments here and on Twitter to let us know you care, even if you can’t contribute.

Related posts:

1. Web Testing for .NET Teams: WatiN or Watir?
2. WatiN Patterns #2: One Assertion and a Name to Match
3. A Common, but Bad, Idea

For those who attended my Agile 2009 presentation with Bob Hartman, “The 7 Deadly Sins of Almost Being Agile,” here are the slides and handouts.

Slides

Evaporating Cloud Cheat Sheet Handout

Evaporating Cloud Template Handout

Related posts:

1. Slides and links from my CU ACM chapter presentation
2. Short Answers #2: What to Focus on in 2009
3. Agile Product Management Boot Camp

Exciting. Entertaining. Do these words describe your sprint demo meetings? Or are boring and unfocused more accurate?

I can’t believe how many times I’ve come in to coach a team and they’ve been surprised when I actually expected to see a software demo in the sprint demo meeting. As the agile principle says, “Working software is the primary measure of progress.” Let’s see some software!

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes, the team’s not actually done. That makes a demo awkward. Other times, they can’t communicate what they did to the Product Owner; they don’t speak “business.” But most often, they simply don’t know how to give a good demo.

So, how do you give a good demo?

Here are a few tips:

• Focus on acceptance criteria. You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done.
• Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story.
• Prepare. Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Watir if necessary to get your app into a state where you can start an interesting demo.
• Practice. Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Camtasia and record yourself giving the practice demo. Painful, huh? That just means you need to work on it.
• Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
• Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.

The sprint demo should be the most exciting part of Scrum. It’s when the team gets to show everyone all the value they’re delivering. That’s worth investing a little time to do well. You may find that previously disinterested stakeholders start coming just for the show.

What has worked well for you in sprint demos? What hasn’t worked? Share in the comments.

Related posts:

1. A Common, but Bad, Idea
2. 7 Tips for a More Effective Daily Scrum
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

The main purpose of the Daily Scrum is for team members to make and follow-up on commitments to one another that work towards the team’s shared sprint commitment. If your Daily Scrum has become unfocused, too long, or otherwise ineffective, here are seven ways to get it back on track.

1. Do it around the task board. Have team members point at stories and tasks on the task board as they talk about their work. This keeps the focus on work for the sprint and makes it obvious when the talk becomes unrelated to the sprint.

2. Change the questions. In “One Word Can Change Your Daily Scrum” I described a way I like to change the three Daily Scrum questions to focus the team on getting things done.

3. Don’t show up. If your Daily Scrum has turned into a status report to the ScrumMaster, try taking a few days off. Let the team report to each other instead of you. Aaron Sanders has more here. Less dramatic ways to have the same effect are avoiding eye contact or stepping outside the circle. But sometimes dramatic is necessary to shake things up.

4. Don’t talk. If you’re not taking sprint tasks, you don’t need to answer the three questions. Emphasize that by not talking at all during the Daily Scrum. Use non-verbal communication when necessary, but keep your mouth shut.

5. Use a parking lot. There are legitimate things for a team to talk about in the morning that don’t fit the tightly-defined purpose of the Daily Scrum. Use a parking lot (i.e. a flip chart or section of a whiteboard) to capture those topics. Address them right after the Daily Scrum is over. You can even let team members add items to the parking lot outside of the meeting to be addressed in the next “parking lot time.” That way, they’re not trying to remember their parking lot topic when they should be paying attention to the Daily Scrum.

6. Actually stand. It shouldn’t be necessary for us to stand to have a short, high-energy meeting, but it really seems to help. If your team has started sitting for the Daily Scrum and it’s running longer than 15 minutes, it might be time to try standing again. Set an example by standing for the whole meeting, and maybe ask one or two influential team members to do the same. Combining this with #1 makes it feel less awkward.

7. Pass a token. Jason Yip describes how introducing randomness and play into the Daily Scrum by tossing a ball to the next person to speak can add energy to the meeting.

What else have you done to keep your Daily Scrum effective? Share in the comments.

Related posts:

1. One Word Can Change Your Daily Scrum
2. Making Velocity Granular Enough
3. A Common, but Bad, Idea

At my current client, we’ve decided to use WatiN, largely for the C# vs. Ruby reason I discussed earlier this week. After spending a week working with WatiN (following a year of rarely using it), I’m impressed. Ruby and the active Watir community still have their advantages. But WatiN has really come into its own with C# 3.0 features like lambdas. I’m pleased with the test code we’re producing in terms of readability, speed, flexibility, and maintainability. I’ve proposed an Agile 2009 tutorial session on the patterns I’m using to get those results, and I’ll post more on that topic here soon. (Which will hopefully help with one of WatiN’s shortcomings—documentation.)

Related posts:

1. Web Testing for .NET Teams: WatiN or Watir?

Bob Hartman and I are offering an Agile Product Management Boot Camp course March 9-10 in Denver. If you’re a product manager, product owner, business analyst or in any other product facing role in an agile (or soon-to-be agile) environment, this intense, hands-on course is a great opportunity for you to ensure that you’re helping your team maximize the value it delivers.

Topics include…

• Understanding Agile: Process and Driving Principles
• Ensuring the Right Things Gets Built: Testing and Acceptance
• Specifying What to Build: User Stories
• Deciding What to Build First: Prioritization
• Defining Customer Value: Minimum Marketable/Releasable Features
• Project Acceptance: Building a Product Vision and Business Case
• Product Management 101: Useful Tips, Tricks and Techniques
• Pulling it All Together: Project Simulation

You will leave the course knowing how to:

• Deal with the team outside of just planning meetings, demonstrations and retrospectives.
• Break down requirements into usable stories – even when the team is unable to help.
• Deliver value in stages rather than all at once.
• Write acceptance criteria to ensure the right features are being developed.
• Create a project business case and vision.
• Perform basic product management functions in an agile way.
• Effectively interact with customers, community, stakeholders, managers, and the team.
• Make a convincing business case for using agile for more projects.
• Continuously improve.

The course registration fee is $1,200, but readers of this blog can take advantage of a special 2-for-1 offer. Simply register with discount code RLB2FOR1, and we’ll send you another code you can give to a colleague to register for free. Seats are limited, so get your registration in today.

Related posts:

1. Free Agile Product Management Seminar – Nov 11, Denver
2. Agile Architecture – Neither BDUF nor Chaos
3. Motivated Individuals

I’ve noticed a pattern with several of my .NET clients who want to get into automated acceptance testing for web applications. They like the idea of WatiN because it would let them write tests in the same language as their production code. But then they notice that there’s much more documentation and apparently a much more active community around Watir. And that Ruby language looks interesting too. What to do?

I think there are good arguments for both. Here are the major pros and cons from my perspective…

WatiN

Watir

The Bottom Line

On balance, I think Watir is the better tool, has the better documentation, the most active community, and the best long-term prospects. But I understand the desire to standardize on C# or VB.NET for both production and test code. The long-term cost of adding another language to a product is not something to ignore.

Personally, I’ll continue to use and teach both tools with clients. When it comes to my own projects, however, I’ll be using and extending Watir, for all the reasons above and simply because I enjoy working with Ruby.

Which do you use and why?

Related posts:

1. A Common, but Bad, Idea
2. UI Sketches for Distributed Teams