More than two years after I originally published it, “Patterns for Splitting User Stories” remains one of the most visited posts on my blog. Splitting user stories continues to be one of the areas where the teams I work with most often need coaching.

To support the teams I coach, I’ve created a flow chart that goes through the questions I’ll ask when I’m helping a team split their stories. I was going to keep this resource for my coaching clients, but I’ve decided to share it here for free. Click the thumbnail below to download the full-size PDF version.

Let me know in the comments if you find this useful. If you can share them, I’d love to see examples of how you’ve used it, what the stories looked like before and after splitting.

Related posts:

1. Another Story Splitting Pattern (Maybe)
2. Patterns for Splitting User Stories
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

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’m experimenting with video for what is likely become a new series here. In these “Short Answers” posts, I’ll answer an agile question in about a minute. Use the comments to suggest questions you’d like to see in future Short Answers.

In this post, I answer the question, “What should I do when I discover in the middle of a sprint that a story is larger than we planned?” Several people have asked me this, and the answer is not, “Suck it up and work 80 hours to get everything done.”

Related posts:

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

The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.

CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs.

For example:

While developing Toyota’s successful 2003 Sienna, the Sienna CE drove his team in Toyota’s previous minivan model more than 50,000 miles across North America through every part of Canada, the United States, and Mexico. The CE experienced a visceral lesson in what is important to the North American minivan driver and discovered in every locale new opportunities for improving the current product. As a result, the Sienna was made big enough to hold full sheets of plywood while the turning radius was tightened, more cupholders were added, and cross-wind stability was enhanced, among many other improvements that resulted from this experience.

(From The Toyota Product Development System by James M. Morgan and Jeffrey K. Liker, p. 30)

If you’ve followed recent discussions on the scrumdevelopment group, you’ve seen multiple threads over the last couple months that discussed how the interests of the team, SM, and PO are intrinsically in conflict and that acting as both PO and SM requires a kind of useful schizophrenia.

I have to wonder: Toyota is one of the best product development organizations in the world. Are Toyota’s CEs a special breed, immune to the conflicts of software teams? Do the rest of us need distinct roles to balance our selfish interests?

At the very least, if we find that the interests of our POs, SMs, and teams seem to be fundamentally in conflict, we should ask why. Shouldn’t we all have the same goal: Producing valuable software now and in the future? Perhaps we should consider how to align around that goal rather than how to balance the interests of roles centered on lesser goals in the hope that we achieve the true goal as a kind of dialectical byproduct.

It’s one thing to say that the PO and SM roles ought not be combined because each is so demanding that it requires a person’s full time attention. But it’s quite another to say that the roles are fundamentally locked in a conflict too intense to be handled by a single person, and that better software results from that conflict.

Related posts:

1. Free Agile Product Management Seminar – Nov 11, Denver
2. Motivated Individuals
3. One Word Can Change Your Daily Scrum

As agile approaches the mainstream, it’s easy to lose sight of some of the core principles, especially this one:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

If agile is to apply broadly, we can’t reserve it just for those projects that start with motivated individuals. We need to learn how to cultivate them.

What makes for motivated individuals on a software team?

1. The belief that the product is worth building. (I consider really interesting technology a special case of this.)
2. The belief that the expectations placed on the team are achievable.

(The book Influencer divides these into Motivation and Ability, but I find that ability so often drives motivation that the two can’t easily be separated. Nonetheless, the book and the authors’ blog are well worth reading.)

Scrum’s sharp distinction between “what to build,” which belongs to the Product Owner, and “how to build it,” which belongs to the team, can create a situation where the team passively builds whatever the Product Owner asks for whether they believe in the value or not. If better software is built by motivated individuals, this is not the way to get it.

This week, I facilitated a project retrospective for a team that struggled with the value of the product they’ve been working on since May. On several occasions, the team was visibly demotivated by the low value they saw in the product. They worked hard and did a good job, but I could tell that they weren’t motivated by the product itself. In the retrospective, one of the answers that emerged to “What should we do differently next time?” was, “Engage the Product Owner in conversations about the value of the product.” Had they done this, the team might have been able to help the Product Owner identify more valuable stories. Or the Product Owner might have been forced to articulate the value of the current stories more compellingly. Either way, the team would have been more motivated to deliver.

The principle I quoted above can be read as, “Find individuals who are already (or inherently) motivated and use them on your projects. Avoid the unmotivated individuals.” That’s fine as far as it goes, but I don’t think it usually works that way. It’s better interpreted something like this: “Find individuals who are open to caring about their work (i.e. potentially motivated). Engage them to become motivated about building something valuable. Let them make delivery commitments they believe they can achieve. Support them and get out of their way.” That’s how you build projects around motivated individuals.

Related posts:

1. Free Agile Product Management Seminar – Nov 11, Denver
2. Agile Architecture – Neither BDUF nor Chaos
3. One Word Can Change Your Daily Scrum

I’m hosting a free seminar on Tuesday, November 11 from 1:00-2:30 PM in the Denver Tech Center area. Please join me there and spread the word to others who might be interested.

Here’s a brief description:

Too many teams adopt agile processes like Scrum and XP, become effective at iterative and incremental delivery, get their software quality higher than it has ever been before, and finally achieve a sustainable pace…yet fail to harness that new productivity to deliver anything of real business value.

As an agile coach, I see Product Owners who don’t understand the features on their Product Backlogs well enough to explain them to the team in a planning session. I see Product Owners who can’t explain the larger context of a user story. I hear teams and Product Owners tell me that it’s not possible to come up with a valuable release that will take less than 6 months to build. I see teams demotivated because they don’t see the value in what they’re building.

In this free seminar, I’ll show how effective agile product management can accelerate and increase ROI, I’ll introduce an approach to identify high value feature sets, and I’ll share some tips on how to avoid getting bogged down in the details and losing the big picture.

You can find more info and register here: http://agileproductmanagement1108-rl.eventbrite.com.

Related posts:

1. How to Invest Less and Make More From Your Software Projects
2. The Most Useful Release Burn-up I’ve Seen Yet
3. Jean Tabaka on “11 Ways Agile Adoptions Fail”