New to agile? Learn how to split stories

In my last blog Agile antipattern: Taking on large stories I said I would give you some tips on how to split stories.  First though, it is important to understand WHY splitting a story well can be helpful.  It is about much more than just making smaller stories.  In fact, making smaller stories may be the least important part of splitting stories.  The most important aspect of splitting user stories is to help make sure the team can be successful.  However, that statement has a lot implied in it.  We need to dig a lot deeper to expose the real reasons for splitting user stories and not just do it as a good practice (we must BE agile vs. DOING agile).  Not that it isn’t a good practice, just that there are more reasons for doing it!

How can the team be more successful by splitting large stories?  Well, my last blog entry on taking on large stories makes it clear one advantage is stories will fit better into an iteration when they are smaller.  But I said making them smaller was not very important, so there must be more to this than meets the eye, right?  Yes, there is!  Below is a list of 10 reasons why splitting large user stories will help teams be more successful.

1. It may be possible to split a story so some of the work on the original story doesn’t have to be done.  Ding, ding!  Huge productivity improvement!  Lean principle alert – eliminate waste!  This reason is good in some many ways you can’t even begin to count them.  Any time work can be eliminated without affecting the overall value of the product it is a good thing.  Oh, and if after splitting the story we see we don’t need to do any of it, well that’s just AWESOME!
2. Stories can be split to expose more personas.  Sometimes teams see a story as large because there are many different types of personas which must be taken into account.  The story becomes easier to deal with, and we gain clarity, when we see the personas split out separately.
3. Stories can be split to help expose risk.  We may have user stories which have elements of risk in them.  If we can split the user story to isolate the risk we may be able to avoid the risk altogether.
4. It may be possible to split a story to ease a transition.  When we upgrade existing functionality we often give users a bit of a shock.  Sometimes we can split stories to give a smaller shock up front and postpone other work until a later release.
5. A split story may be able to have more people work on it at once (swarming).  If a story is large and requires primarily one type of expertise we tend to let a single person do all of that type of work.  However, a split story may enable others to chip in because some portions of the large chunk of work can be handled by people with less expertise.
6. Splitting a story may give us more visibility into its true size.  I have seen many teams split a size 13 story into 3 pieces and end up with 3 stories each of size 8!  In fact it isn’t even that uncommon.  When we have an upper bound on our story size we tend to use that size for anything “big.”  This leads to large under-estimating for truly large stories.
7. A story split may allow us to use a different quality standard for the new stories.  A simple example in a reporting system may be two of the same type of report, but one is run hourly and one is run yearly.  The hourly report may need higher quality than the one run yearly.  This may be a bad example, but I think it gets the concept across.
8. When a story is split correctly it can help with testing.  Some portions of the story may require full end-to-end testing, while other portions may be able to be tested in a mock environment.
9. A split story may isolate performance factors.  One portion of the original story may affect performance while another does not.  This may affect prioritization as well as performance testing time.
10. Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.

Those are all good reasons for splitting user stories, but I haven’t really told you how to do it.  That’s because I don’t have to.  My good friend and fellow founder of the Agile Cooperative, Richard Lawrence, recently had a blog entry on Patterns for Splitting User Stories.  He explains it much better than I ever could!  In fact, he explains it so well that Dean Leffingwell is going to be using Richard’s work in his next book.  High praise indeed.

Until next time keep Making Agile a Reality^® by splitting those large stories!

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.