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.

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?

Most Ruby programmers know about Ruby’s interactive console, IRB. (If you don’t, stop right here, open up a command window and run irb. Type some Ruby code. See how it returns the result of each line right away.) IRB is great for poking around with unfamiliar libraries.

Suppose you’re using Capybara with Cucumber for the first time. It would be nice to use IRB to experiment with what Capybara can do on a particular page. You could launch an IRB session and duplicate all the Capybara setup from your Cucumber support/env.rb file. But wouldn’t it be nice if you could just fire up IRB in the context of a step definition so you know everything in your IRB session matches what you’d get in the step def? Turns out you can. Here’s how…

Install the ruby-debug gem. If you’re using Ruby 1.9 like me, you need the ruby-debug19 gem. In Rails 3, just add gem ruby-debug19 to your Gemfile, probably in the test group, and run bundle install.

Require ruby-debug in support/env.rb.

Add breakpoint where you want to jump into IRB. For example:

(Note the extra line after breakpoint with 0 on it. breakpoint breaks before executing the next line, so if it’s the last thing in a block, you won’t jump into the debugger in the context you expect; 0 is a dummy line to keep us in the right context.)

Run Cucumber like normal. When it reaches breakpoint, ruby-debug will take over, and you’ll see a prompt like this: (rdb:1).

You can do a lot of different things at this prompt, but we only care about one right now: type irb and hit Enter. Now you should see a an IRB prompt. You’re in the context of a Cucumber step definition. Type self and hit Enter. You’ll see that self is an instance of Cucumber’s World with various things mixed in. From here, you can do anything you would do inside that step definition.

When you’re done, run quit to get out of IRB and continue to get out of the debugger. Cucumber execution will continue like normal. Keep in mind, though, that if you change the state of your system from IRB, you might not get the test results you expect.

Enhancements and variations for you to explore:

• Make IRB nicer to use with gems such as irbtools
• Create a step definition just for launching the debugger
• Create a tagged scenario just for launching the debugger

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?

You may not realize this: Tables in Cucumber steps don’t have to have a header row. Sometimes it can work really well to use a headerless table of key-value pairs.

Let’s look at an example. Suppose we have a scenario that fills out an advanced search form to search for medical providers matching certain criteria. A mockup of the form looks something like this:

If we were using the recently deprecated web steps generated by cucumber-rails, we might write steps to perform a search like these:

But we know better than to do that, right? After all, we’re trying to describe how the search logic should work, not how the form should look. So we try to write our own steps to do these same thing without talking about the implementation so much, but it’s really hard to get away from the implementation. Even if we drive out words like select, fill in, and click, we still have a step per form element.

Suppose we try to combine them into a single step for the domain concept of performing a search. We might get something like:

The implementation details are gone, but it’s long and hard to read. Enter the key-value table:

In the step definition, we can use the rows_hash method on the table object to convert that key-value table to a single hash. There’s no need to iterate through the rows ourselves. For example, assuming a helper method called provider_search that actually performs the search,

You may have noticed the call to to_bool. This uses a helper method like the following to allow us to use yes and no instead of true and false to make more readable scenarios. Put this somewhere in the support directory.

The call to to_i on the search radius takes advantage of Ruby’s string to integer conversion behavior—if a string starts with an integer but has other text after the integer, the other text is stripped off during the conversion. Try it: Fire up irb (the interactive Ruby console) in a command window and run "5 miles".to_i.

These key-value tables can get long for a complex entity. Not all the details will matter each time. We can make the step read better by introducing a concept of a default provider search. Maybe we have to supply a ZIP code and search radius, but the scenario we’re working on is really about specialties and insurance. We could say,

In the step definition, we’ll declare the default values in a hash and merge it with the supplied values.

If the defaults are well known, this is enough. If they need to be documented, one way I like to do it is as executable documentation with a scenario like this:

If you do this, you’ll want to move the default criteria hash into a helper method or constant to make sure it’s the same hash used in the real scenario and the documentation scenario.

We could make the step definition read better by separating the key and value conversions from the use of the data. Cucumber’s table object has map_headers! and map_column!. Unfortunately, those don’t work for rows_hash at this time. I recently submitted a pull request to make it work. Hopefully, we’ll see that in a Cucumber release soon.

Beginning just over two years ago, I worked with some great developers to create Cuke4Nuke as a way to bring Cucumber to .NET. Shortly after the first releases of Cuke4Nuke, TechTalk released SpecFlow, a native .NET tool inspired by Cucumber. As a pure .NET solution without Ruby dependencies, SpecFlow seemed to be easier for Microsoft shops to adopt. But Cuke4Nuke had (to me) enough advantages that I kept it going.

By this summer, however, it was clear that SpecFlow had made up for most of Cuke4Nuke’s advantages and had more momentum in the .NET community and was under much more active development. There were just a few gaps SpecFlow needed to overcome (in my opinion), mostly related to better harmonization with the other Cucumber projects. (With the pure Java Cucumber-JVM under active development as a Cuke4Duke replacement, there was no longer as compelling an argument for shared code between Cucumber versions, Cuke4Nuke’s biggest remaining advantage.)

At AA-FTT and later in the week at Agile 2011, my colleague Paul Rayner and I met with Christian Hassa and Gaspar Nagy from the SpecFlow team. We discussed the few things that needed to change in SpecFlow to make it behave more like the other Cucumbers.

This week, most of those changes were released as part of SpecFlow 1.8. With that release, I’m letting Cuke4Nuke die. I won’t be maintaining or extending Cuke4Nuke. My Cucumber classes and book will cover SpecFlow rather than Cuke4Nuke.

I’ve had a great time getting to know the SpecFlow guys, and I look forward to collaborating with them in the future to help bring Cucumber to more and more teams in the Microsoft world.

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.

Regular expressions are a big part of what makes Cucumber tests both expressive in English and DRY on the automation side. To make the most of that power, you have to know something about regular expressions.

I’ve created a cheat sheet for my Cucumber class workbook based on last year’s “Just Enough Regular Expressions for Cucumber” post. Download and print a copy to post by your computer until regular expressions become natural for you:

Cucumber Regular Expressions Cheat Sheet

The Ruby version of Cucumber isn’t just for Rails developers. If you have a .NET or Java web or service app, Ruby can be a great language for testing. With libraries like Capybara for driving web apps and JSON, RestClient, SOAP, and others for interacting with service apps, you’ll find testing in Ruby requires much less code than in C# or Java.

It can be hard to find instructions for setting up Ruby and Cucumber on Windows, though, so I’ve compiled these to help my clients get started, and I thought they might be useful to others. I’ve tested this on a clean Windows 7 VM, and everything works. Your mileage may vary, but let me know if you have any issues.

1. You’re going to be working in a command window quite a bit with Cucumber. You may want to customize your command window to make it more pleasant to use. I like the following settings (right click on the top left corner of the command window and choose Properties to set these):
   Font: Consolas, 20pt
   Screen Buffer: 120×3000
   Window Size: 120×60

   On a smaller screen, you’ll of course want a smaller window size and screen buffer. If you’re on an earlier version of Windows, you won’t be able to choose Consolas for the font, but Lucida Console is still better than the default.

   I also like to set a PROMPT environment variable to $P$_$+$G (right click on My Computer and choose Properties, then Advanced, then Environment Variables).

2. Download and install Ruby. For Windows, http://rubyinstaller.org/ is the best option. Install the latest release of version 1.9.2. Make sure you check the option to “Add Ruby executables to your PATH.”
3. Also install the Ruby Development Kit from the same place, which will allow Ruby to build native extensions for libraries. Instructions are available here: https://github.com/oneclick/rubyinstaller/wiki/Development-Kit.
4. Confirm that the installation worked by opening a command window and running ruby -v. You should see a description of the Ruby version installed. If you see an error, something went wrong with the installation.
5. Make sure you have RubyGems installed by running gem -v on a command line. RubyGems is the package manager for Ruby and should come with the standard Ruby installation.
6. Run gem install cucumber to download and install Cucumber. Run cucumber --help to confirm that it worked.
7. Cucumber complains that you need ANSICON to get console colors because Windows doesn’t understand ANSI color escape sequences. Download ANSICON from http://adoxa.3eeweb.com/ansicon/. Extract it somewhere (I put it in c:utils). In your command window, cd to either the x86 or x64 directory where you extracted ANSICON, depending on your OS, and run ansicon -i. Exit that command window and open a new one. Now, when you run cucumber --help, you should no longer see the message in the output about needing ANSICON.
8. Run gem install capybara to download and install the Capybara web automation library.
9. Run gem install rspec to download and install a nice library for readable assertions (among other things).
10. You’ll want Firefox with the Firebug plugin to do UI-related tests. If you haven’t already, install those.
11. You can edit Cucumber tests and automation code in Notepad, Visual Studio, or any other text editor. But I like having an editor that knows about Cucumber and provides Cucumber-oriented features, so I use JetBrains RubyMine to work with my Cucumber tests. There’s a free 30 day trial available.
12. To make sure Cucumber and Capybara are working nicely together, download and extract this Ruby, Cucumber, and Capybara Starter Project somewhere on your machine. Open a command window at the root of the folder (if you run dir or ls there, you should see a “features” folder). Run cucumber, and you should see all the tests run and pass.

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?