Making Agile a Reality®

New Story Splitting Resource

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. You’re welcome to print copies for personal use.

Your template is great! I would love to make a german translation of your flowchart and republish it. Let me know if you would favor this and how I should credit Humanizing Work properly if you are interested :)

Awesome! Thanks a lot for sharing it!
I would love to translate it to spanish if you allow me to do it. It must be a nice tool to explain user stories splitting on workshops. I have discovered it’s difficult for me to explain my intuitions :)

@Isabel – Thanks for the comment. There isn’t a Spanish version yet. I have the translated strings, but I haven’t yet had time to turn them into a poster. As soon as I’m done, I’ll post it on this blog.

Hi Richard,
thanks a lot for sharing this nice template. Together with your post on ways to split a user stories it’s highly valueable for me. I’ll immediately forward and discuss this with our product owners.

Hi Richard,
Thanks for creating this chart. I would like to translate it in French so I can use it in my Agile training sessions. I saw Patria asked for a French version too. Do you authorize me to make it?

What can be added to the splitting approaches:
Split along role: Some stories involve more than one role doing different tasks. Each implementation should only concern one role, so we should have stories per role doing a task.
Split along dimensions: Dimensional planning allows us to define different “levels” of implementation for each story. This means that we can have the same functional story, but the implementation has to comply with more or fewer non-functional acceptance criteria.
Split along value stream: A process may be applied to more than one value stream to produce different categories of output. Some of those streams may bring in more value than others.
Split along risk: One part of a value stream, process or user story may be riskier than another.

Also please contact me if you were thinking about creating the Russian version of the cheat-sheet. I can help you with that.

@Andrew – Glad your team likes the poster. I’m fine with anyone printing it for their own use. I probably should update the copyright notice to reflect this. Meanwhile, this comment should be sufficient permission for you to get it printed.

I either use Fedex Office or Mimeo.com to print them, depending on how many I need and how fast I need them.

Hi Richard, thank you very much for the great post. One question though: When you say “Is User Story size is 1/10 to 1/6 of your velocity”, what do you mean? I am not sure how we can compare size with velocity (different units).

@nataliya – In my experience, the sweet spot for small enough but not too small is when you can get about 6-10 stories in an iteration. So, if your velocity is 30 points, most stories should be 3-5 points. In practice, since the whole team sizes stories but just a subset of the team usually splits, I suggest just asking yourselves, “Could we do 6 of these in an iteration?”

I see that you’ve published a translation of my original splitting article on your website without attribution or a link to the source, so that it looks like you created the content. I’d prefer that you not do that.

However, I’d love to see a Chinese translation of the story splitting poster published here as we’ve done for Spanish, French, German, and Russian. I’ll email you the info on doing a translation. Thanks!

Hi, Michal. No, it’s in English, Spanish, French, German, Russian, and Chinese. Is there large Polish-speaking audience that doesn’t read one of these other 6 languages? We support the translations as a community service—it takes a lot of time, and the people who use them are not potential customers (because we only teach in English)—so we try to make sure there’s sufficient need before doing a particular language. With several other language like Hindi, Italian, Danish, and Dutch, we determined it wasn’t worth the effort. I’m curious about your thoughts with respect to Polish.

To be honest I am surprise that no one try to translate already as this is very good document. Of course most of polish people speak English in level to understand this document :)
I will just translate it for my own needs and to understand it better. Then will show it to my friends Scrum Master at work. If they will see value in polish translation will come back to you.

You’re welcome to print and distribute the poster in your company, as long as it’s as-is, without any modifications.

You might also want to check out my 80/20 Product Ownership online course as a resource for your group. I explain the patterns in more detail, and I teach a variety of related techniques you’d find useful. You can email me for a group discount: my first name dot last name at agileforall.com.

You’re welcome to print and distribute the poster in your company, as long as it’s as-is, without any modifications.

You might also want to check out my 80/20 Product Ownership online course as a resource for your group. I explain the patterns in more detail, and I teach a variety of related techniques you’d find useful. You can email me for a group discount: my first name dot last name at agileforall.com.

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches teams and organizations to become happier and more productive. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room.