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

Atul Gawande is a surgeon and author who has written some excellent books and New Yorker articles reflecting on the state of modern medicine. Recently, his writing has gone beyond medicine in interesting ways. As he looks for lessons for medicine from other disciplines, he ends up with things to teach both medical professionals and skilled knowledge workers more generally. His book The Checklist Manifesto manages to be a riveting 224 pages on what ought to be one of the least interesting topics possible: the checklist.

So I was intrigued to see a link to a New Yorker article from Dr. Gawande on my own specialty, coaching. It’s as good as I might have hoped. Noticing that his own performance as a surgeon seems to have plateaued, he wonders whether a brief experience with a tennis coach might apply to surgery:

One July day a couple of years ago, when I was at a medical meeting in Nantucket, I had an afternoon free and went looking for someone to hit with. I found a local tennis club and asked if there was anyone who wanted to play. There wasn’t. I saw that there was a ball machine, and I asked the club pro if I could use it to practice ground strokes. He told me that it was for members only. But I could pay for a lesson and hit with him.

He was in his early twenties, a recent graduate who’d played on his college team. We hit back and forth for a while. He went easy on me at first, and then started running me around. I served a few points, and the tennis coach in him came out. You know, he said, you could get more power from your serve.

I was dubious. My serve had always been the best part of my game. But I listened. He had me pay attention to my feet as I served, and I gradually recognized that my legs weren’t really underneath me when I swung my racquet up into the air. My right leg dragged a few inches behind my body, reducing my power. With a few minutes of tinkering, he’d added at least ten miles an hour to my serve. I was serving harder than I ever had in my life.

Not long afterward, I watched Rafael Nadal play a tournament match on the Tennis Channel. The camera flashed to his coach, and the obvious struck me as interesting: even Rafael Nadal has a coach. Nearly every élite tennis player in the world does. Professional athletes use coaches to make sure they are as good as they can be.

But doctors don’t. I’d paid to have a kid just out of college look at my serve. So why did I find it inconceivable to pay someone to come into my operating room and coach me on my surgical technique?

The rest of the article wanders through a history of coaching; interesting examples from sports, music, and education; and describes his own experience engaging a coach. He concludes,

There was a moment in sports when employing a coach was unimaginable—and then came a time when not doing so was unimaginable. We care about results in sports, and if we care half as much about results in schools and in hospitals we may reach the same conclusion.

I value coaching enough to spend my own money on it. I’ve hired a mountain bike coach, Lee McCormack, to help me prepare for this summer’s Trestle All Mountain Enduro race. It’ll be my first downhill race. I don’t expect to win, but I want to get a result I can be happy about and enjoy the experience.

I used to do cross-country mountain bike races, and I have a pretty good idea how to train for an event. I have Lee’s books. I could probably do this on my own. But I know from my own experience as a software development coach how much faster a good coach can help you improve.

Lee McCormack on his backyard pump track

After just two hours of coaching—working on things I would have said I already knew how to do—I could see a marked improvement in my skills. And I had a nice list of things to practice on my own.

This brings me back around to software development. Our world today runs on software. But most software teams struggle to deliver anywhere near as quickly and reliably as they could. A software profession living up to its potential would transform the world. So, to paraphrase Gawande: If we care half as much about results in software development as we do in sports, how is it imaginable that so few teams engage a coach? How is it imaginable that so many teams with access to coaching fail to make the most of it?

What about your team? Do you have a coach? If so, do you make the most of the coaching you have available to you?

Related posts:

1. Refactoring Things Other Than Software
2. How to Invest Less and Make More From Your Software Projects
3. UI Sketches for Distributed Teams

The task board is a simple, yet powerful, tool for Scrum teams. As a coach, I can tell a lot about a team just by looking at their task board in the middle of a sprint. If your Scrum team is in the same location, I can’t think of a good reason why you wouldn’t want to build and use a task board.

Here’s how to build a basic task board, various ways to enhance it to convey more information, and some analysis of the many things you can learn from this simple tool.

Supplies Required

• A black or blue poster marker
• A black fine tip marker
• 3 inch square Super Sticky Post-It notes in yellow (generic sticky notes tend not to stick for a whole sprint)
• A large surface (e.g. whiteboard, foam core, smooth wall, etc.)

Optional Supplies

• Blue and red fine tip markers
• Two 1″ photos of each team member
• Larger sticky notes in another color such as blue or green
• Square or small sticky notes in orange or red
• Removable, semi-transparent color dot stickers
• Narrow electrical tape
• Story Definition of Done printed as checklists
• Post-It glue stick
• Blue masking tape

Basic setup and use

Make sure you place your task board where the team will use it. Ideally, the team is in a team room together and the board is in the same room. At the very least, it should be in a place where the team will see it several times a day. It’s very valuable to use the board to focus the Daily Scrum, so there should be enough space for the whole team to stand around it.

On your task board surface, mark out the following columns with marker or tape: Story, Not Started, In Progress, Done.

Create a card (on a sticky note) for each story you committed to in the current sprint. If you have two colors of stickies or a larger sticky available, use that for the stories. Use the black fine marker to write a title for the story in large, clear print. If the story is in the typical “As a , I want so that ” format, you’ll want to shorten it to a 3-6 word title. You can write the full story on the card with a pen if you want. Write the story point estimate on the card, in a different color marker if you have one. The story titles on the cards should be readable from about 6 feet away. Arrange the story cards in priority order in the first column, leaving space between them. Each story thus defines a horizontal lane across the board. (I don’t recommend drawing or taping horizontal lines, though; different stories need different amounts of space at different times.)

Create a card for each task you’ve defined. Again, use the black fine marker and a short title to make them readable from 3-6 feet away. Arrange the tasks in the Not Started column with their corresponding story.

Some teams generate all or most of their tasks at sprint planning. Some generate tasks as they start a story or just-in-time. Still others don’t use tasks at all. If you generate tasks throughout the sprint, you can expand and contract the story lanes to make room for tasks as needed. If you don’t use tasks, you’ll want to eliminate the Story column and move the story cards through the other three columns.

Tasks will almost always be placed on the board in the Not Started column. As a team member assigns a task to himself, he’ll write his name or initials on the card and move the card into the In Progress column. When the task is done, he’ll move it into the Done column and likely choose another task to start.

The basic board should look something like this:

Enhancements and variations

If you have photos for each team member, attach them to small sticky notes or put Post-It glue on the back. Place the photo stickies on the edge of the board to indicate team members available for tasks. I suggest only making one sticky per person readily available. You can have a second sticky available for the rare times a task is blocked and they need to work on a second task. Instead of writing their names on tasks, team members will use their photo to indicate task assignments.

Make a half- or quarter-page checklist for your story definition of done. Print a stack of them. Place one on the board for each story and use it to make sure you generate the right tasks and actually reach done for the story.

If you regularly get work outside your sprint commitment that has to be addressed right away, such as production support, consider adding an “Expedite” lane above the first story. When something new appears in the Not Started column on the Expedite lane, the team focuses on that item rather than stories in order to get it done as soon as possible. (If the “urgent” item doesn’t trump the other stories, it probably should be added to the product backlog and wait until a future sprint, so this rule is a good way to distinguish between truly urgent work and someone just trying to change the team’s priorities mid-sprint.)

Use the red or orange stickies to represent impediments. Place them directly on the items they’re blocking. This avoids the disconnect between an impediment list and the task board and may explain otherwise strange indications on the board (e.g. a high-priority story in progress while low-priority stories get done).

Use different color cards or dots on cards to indicate themes, larger features, dependencies on other teams, etc.

Consider setting a WIP limit, a restriction on the number of stories you can have in progress at once. Post this number in the header of the In Progress column. Note: It’s helpful to write “limit 3 stories” rather than just “3″ because you’re limiting the number of stories in progress even though the column actually contains tasks.

What the task board can tell you

What have we committed to? The stories on the left of the board reflect the team’s commitment for the sprint. Because they’re readable at the 6′ distance, someone can see the overall commitment at a glance.

What’s done? Assuming you’ve created all the tasks for a story to get done, the presence of all a story’s task cards in the Done column indicates that the story is done.

What are we currently working on? The presence of task cards in In Progress indicates that the team is currently working on the corresponding story.

Are we working on the right things? Since stories on the task board are ordered according to their priority in the product backlog, the top stories should be getting to done first. If stories in the middle or at the bottom of the board are done while stories at the top are not started or in-progress, this can indicate a problem. For example, maybe there’s an impediment blocking a high-priority story but no one is talking about it.

Are we working together? The number of stories in progress and the distribution of names reveals whether the team is collaborating or whether each team member is working on her own story.

What’s blocked? If you use impediment stickies, you can see at a glance what’s blocked and make sure something is being done about the impediment.

How much urgent/unplanned work is being added? If you use the Expedite lane, you can see by the accumulation of cards how much work has been added after the start of the sprint. This may lead the team to discuss with the Product Owner dropping one or more stories from the bottom of the board.

What work should I do next? When you’re ready for a new task, the task board can tell you which stories are open so you can find a way to contribute to the highest priority open stories rather than opening a new story.

Next steps

Check out fellow CSC Xavier Quesada Allue’s excellent blog on visual management, which covers this topic in much more detail.

Share in the comments: How have you made the task board work better for your team? Which suggestions from above are you going to try?

Related posts:

1. 7 Tips for a More Effective Daily Scrum
2. One Word Can Change Your Daily Scrum
3. How to Give a Great Sprint Demo

As a coach, I’m frequently told, “Our sprint length is too short. We want to change it from X to Y weeks.”

The time box—the sprint in Scrum, the iteration in XP and other iterative methods—is one of the most powerful tools in agile software development for revealing problems in a team or organization. Notice I said reveal, not fix. I’ve seen a few cases where the sprint length really was too short. More often, though, the feeling that the sprint is too short is a sign of deeper problems. Lengthening the sprint might push these problems back under the surface, but it’s unlikely to actually solve them.

Before you increase your sprint length, ask “Why?” a few times to see if you have any of the following underlying issues, and try to deal with those first. Maybe your sprint really is too short. But don’t start there, lest you miss an opportunity to improve.

Underlying Problem #1—You’re trying to do “mini-waterfalls”

It’s very difficult to fit a mini-waterfall cycle into 1 or 2 weeks. If you regularly find that testing starts late in the sprint and gets less time than it deserves, experiment with something like ATDD to move testing earlier in the work and try working on fewer stories at a time.

Underlying Problem #2—You struggle to split stories

To maximize predictability without too much overhead, I recommend 6-10 stories in a sprint. Sometimes teams want to increase their sprint length because they struggle to get even one story small enough to fit into 2 weeks. Instead of increasing the sprint length, work on your story splitting skills for a while. Splitting stories is a skill that takes time and practice to develop.

Underlying Problem #3—Meetings take too long

Perhaps your Scrum meetings, especially Sprint Planning, are long and painful. It’s natural to want to do them less often. But consider this: Do you expect to do 50% more work in 3 weeks than you did in 2 weeks? Probably. Then you’ll have 50% more to talk about at Sprint Planning. The most effective hour of a meeting is usually the first hour. After that people, get tired and distracted and accomplish less. So, by increasing the content of your planning meeting by 50%, you’ll probably increase the total meeting time by more than 50%. True, it will happen less often. But it will be even more painful than today.

Instead, work on getting better at your meetings. One team I coached decreased their bi-weekly Sprint Planning meeting from 10 hours to 20 minutes by

1. doing regular backlog grooming every day or two for very short periods with just the necessary team members,
2. planning using story point velocity rather than task estimates,
3. creating tasks just-in-time during the sprint, and
4. doing Sprint Planning in multiple passes, a high-level initial discussion and commitment based on velocity and then more detailed discussion of each story as needed.

Could one or more of these techniques help you?

Underlying Problem #4—Deployment (or merging or integration or whatever) is too hard

Perhaps you try to deploy completed stories into some kind of staging or formal test environment at the end of each sprint. Maybe you even need to engage outside release managers to do it. It’s difficult and time-consuming to do, so naturally you want to do it less often.

I wholeheartedly agree with the advice in Jez Humble and David Farley’s excellent book, Continuous Delivery: “If It Hurts, Do It More Frequently, and Bring the Pain Forward.” (p. 26) Instead of deferring the pain—and probably making it worse in the process—try to make it less painful so you can do it more often. If deploying every sprint is hard, figure out how to deploy nightly or on every commit. (Continuous Delivery is a great resource to start this journey.)

Underlying Problem #5—You can’t get anything done in 2 weeks

Sometimes teams tell me, “We simply can’t deliver anything valuable in 2 weeks, so we have to go to a longer sprint.” But changing your sprints from 2 to 4 weeks really hasn’t changed how much value you deliver in 2 weeks; it’s just given you half the visibility into progress. Instead of changing the sprint length, try these two things:

1. Use a concept like the Minimum Marketable Feature to group user stories into larger units of value. You’ll still work on stories, but you’ll have better visibility into how those stories contribute to releasable value.
2. Do some root cause analysis (e.g. the 5 whys or a similar tool) to find out why you deliver less value per week than you’d like. Maybe you have some technical debt you need to deal with. Maybe you have too much process overhead. Maybe a specialist is a bottleneck because skills are unevenly distributed on your team. Maybe you’re building on an out-of-date platform and could get more productivity with newer technology. There is a wide range of possible causes for low productivity. Whatever the cause, longer sprints are unlikely to be a fix.

Underlying Problem #6—It takes too long to get feedback

If the Product Owner takes a week to answer questions, it probably going to be very difficult to complete work in a 1 or 2 week sprint. But will a 3 week sprint be much better? Instead, find ways to shorten feedback cycles such as,

1. take other responsibilities away from the PO so she can focus on her role,
2. give the PO (or team) more authority to make decisions without having to ask hard-to-reach stakeholders, or
3. work to increase knowledge on the team to reduce the number of questions that need to go to the PO or outside experts (ATDD can be a great tool to accelerate this learning, especially if you use it to build a ubiquitous language).

Underlying Problem #7—Dependency on outside specialists

Related to #6, sometimes teams can’t complete a story without help from a specialist outside the team—a DBA, tech writer, expert on a particular technology, etc.—and this outside person is part-time on many teams. Before lengthening the sprint to work around this issue, try to reduce the dependency by

1. moving the specialist into the team,
2. reducing the specialist’s load so he can be more available to the team, or
3. growing the team’s own skills and/or authority in the speciality area.

Conclusion

If you’ve dealt with all the underlying problems you can find and your sprints still feel too short, then by all means, try a longer sprint length. Make your process for you. Just don’t start by lengthening your sprint and miss out on an opportunity to improve.

Related posts:

1. A Common, but Bad, Idea
2. Growing DONE—How to Make the Definition of Done Work for Your Team
3. How to Give a Great Sprint Demo

User stories are typically written using a template like, “As a <role>, I want to <action> so that <value>.” My other story splitting patterns focus on complexity in the action part of the story. But sometimes the functional complexity in a user story is hidden in the role rather than the action. Consider: could you split the story by splitting the role and only satisfying a subset of potential users in the first story?

As the title suggests, I’m not sure this is actually a new pattern. Every example I can think of actually fits under another pattern. So, if you like, you can think of this as a thought experiment to identify simple/complex, business rule, data entry or other splits where splitting the role reveals a split somewhere else.

Share in the comments: Has discussing splitting the role for a story ever helped you find functional complexity to split the story? Can you provide an example? Is this a sufficiently distinct pattern to merit updating the original article?

Related posts:

1. Patterns for Splitting User Stories
2. Agile Product Management Boot Camp
3. How to Give a Great Sprint Demo

Focus your team on predictability, and productivity will come. Focus on productivity, and you’ll get neither productivity nor predictability.

Focusing on predictability drives a team to:

• Small user stories that can be completed in a day or two
• Working on a small number of stories at once
• A strong story definition of done with little or no gap between it and the release definition of done
• Individuals crossing disciplines to get things done without unpredictable wait times
• Making achievable commitments based on past results

On the other hand, focusing on productivity—usually leads to:

• Individuals optimizing for their own productivity (i.e. lots of tasks getting done)
• Over-committing
• Starting stories without necessarily believing they’ll get done (“If we’re going to get all these stories done in this sprint, we’d better start them as soon as possible!”)
• Sacrificing quality for speed (i.e. taking on technical debt—”Just get it done; we’ll clean it up later.”)
• Communicating and collaborating less (“All that conversation slows me down. I need to focus on my work.”)

The (ostensibly) productivity-focused behaviors may show a velocity increase in the short term. But you’ll pay for it later. More likely, you’ll see an erratic velocity, sometimes high, sometimes zero. And there is likely to be some nebulous chunk of work between the last story and the release.

Over and over again, I’ve seen the predictability-focused behaviors lead to a stable or, more often, a slowly increasing velocity. Small stories are easier to estimate and to get done right. Building quality in keeps the system easy to maintain and extend. And when done really means done, the Product Owner can make meaningful predictions and commitments around delivery. “Working software is the primary measure of progress,” after all.

Note: This assumes energized work. If your team doesn’t care about getting anything done, they could predictably deliver nothing, which isn’t particularly satisfying. With this team, focus on motivation, then predictability. As the Manifesto also says, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Motivation comes first.

Related posts:

1. The Most Useful Release Burn-up I’ve Seen Yet
2. Motivated Individuals
3. One Word Can Change Your Daily Scrum

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