Better scrum user stories: Split stories horizontally, not vertically

Teams often run into trouble in a sprint when they’re trying to work with poorly split stories. Stories that are too big, too small, confusing or that mix the problem with the solution

We should split stories into small, discreet chunks of functionality. A single story should generally be the smallest discreet piece of functionality that adds business value. What is sometimes forgotten is that a single story should also have a complete user experience flow – it should bring the user from a determined start point to a complete, useful end.

When splitting large user stories down into smaller ones, remember to ensure the story captures a complete user flow. When splitting, think splitting horizontally, not vertically.

A horizontally split story will show a single flow, or path, through a user journey. (For example, a payment process that covers the simplest functionality, a single payment type, inability to modify your order, etc. The options are very limited, but the user is able to reach a useful end – ie, they can pay for something.)

A vertically split story will show multiple paths through a flow, but will stop before the flow can reach a useful end. (For example, a payment process that covers, at once, all the different payment methods that you ultimately want to support, but not the surrounding user flow.)

The problem with splitting vertically instead of horizontally is that vertical ‘strips’ have the entire complexity of the full, complete solution, but you lose the ability to test the whole flow properly. It is also far more tempting to dive into a pie-in-the-sky architecture discussion because to build all the full options for this one strip requires an understanding of all the inputs and outputs of the flow – most of which probably don’t exist yet.

An incomplete flow not only adds no user or business value to your product, but it’s very difficult for teams to build effective solutions for incomplete flows. Think and split in terms of thin, horizontal flows, and increase complexity with additional horizontal ‘layers’ (additional stories).

Advertisements

About Will

I'm Will. I'm a product creator, Scrum and Agile advocate, web enthusiast and change instigator. I work for Nokia and I am the Product Owner of Nokia's web social location platform, maps.nokia.com
This entry was posted in Agile, Scrum and tagged , . Bookmark the permalink.

6 Responses to Better scrum user stories: Split stories horizontally, not vertically

  1. Agile Scout says:

    Interesting points here… if you were to do a search for splitting user stories you’ll find plenty of examples of people saying that you should split vertically…
    Is the answer: “It depends?”

    • Will says:

      True, good point. The answer probably is “it depends”… It depends a lot on the nature of the stories that you’re splitting down, and of course on the software that you’re building.

      Probably the most important thing is making a conscious decision to do it one way or the other; and understanding the difference. To me, splitting stories into vertical chunks makes it complicated to add business/user value incrementally, as most vertical strips are, from the user’s perspective, worthless without the adjoining chunks that go together to create the whole flow.

      I wonder what would be some good examples of situations where vertical strips would be better…?

  2. Erik Gibson says:

    This assumes the user-facing articulation is to one side of your mental image. I’ve always pictured the user at the top and encouraged teams to work in narrow vertical slices and avoid a layering approach which doesn’t deliver functionality to the user until most of the underlying structure is built.

    • Will says:

      Hi Erik,
      It’s a good point – and to me, ensuring that subsequent stories add consecutive value is the most important thing.
      I think of a complete user flow as one horizontal ‘chunk’. I use the word ‘horizontal’ because to me the user journey goes from left to right; from A to B.

      This chunk is made up of multiple flow possibilities and combinations; something like a network with many different possible routes (each possible route representing another way for the user to complete the intended task – different entry points to the flow, different options, different settings, differently formatted output, etc). The first step, the very first user story, is the simplest path through this network that gets the user from start to finish. This is the first, most basic ‘horizontal’ story.

      This first story delivers value to the user immediately, as they are able to move from one side of the flow (intended action) to the other (response). Subsequent stories, or horizontal layers, add additional functionality (or, in other words, enable other paths through the network).

      Potentially we are talking about the same thing, but with a different perspective on horizontal vs vertical?

  3. I agree entirely with what you’re saying, but the standard nomenclature is as Erik suggests, with architectural slices horizontal, e.g. http://en.wikipedia.org/wiki/Multitier_architecture

    Also, these blog posts on the same topic use the conventional names:
    http://stevesmithblog.com/blog/stories-too-big-ndash-vertical-slices/
    http://agilewarrior.wordpress.com/2009/07/27/horizontal-vs-vertical-slicing/
    http://www.rapaul.com/2011/02/27/vertical-slicing/

    Perhaps a little note about this at the top of your post would be helpful, as I think a lot of people could be confused, as your article ranks very highly in Google!

    • Will says:

      Hi Andy, thanks for the comments. I’ve been thinking about this problem for a while, as I recognise that how I have described the problem contradicts with how others describe it. The more I think about it, the more I believe there are actually (at least) two different concepts at play here; concepts that need to be split separately; one vertical and one horizontal…

      Let me explain my thinking. The splitting that the blog posts above, as well as the wikipedia article, seem to be concerned with splitting a problem or a team along the technology stack/architecture. Here, it makes total sense to split vertically (and ‘vertical’ is also absolutely the appropriate term). The presentation layer should be combined with the data objects, business objects and database to remain a concise, effective user story that avoids “just-in-case” work as well as ensures a cohesive user experience.

      However, when I’m thinking about splitting large user experiences into smaller ones, I think not in terms of architecture or stack – but in terms of _flow_. The user _flows_ along multiple paths through an application or experience. From A to B. Here, it seems logical to me to consider a user flow through an application to be a horizontal journey. Like walking from here to there… it’s a naturally horizontal experience. When designers print out screen designs on multiple pages to show flow, they are normally laid out on a table in a horizontal fashion, not vertical. Hence, I tend to think of user flow as a horizontal experience. Now, when splitting a horizontal flow into smaller flows (or user stories), it makes sense to take horizontal slices to ensure that a single slice can still provide user value (complete a flow).

      An example: consider this problem: “As a user, I want to search for and find places on a map and get information about them.”

      I lay this flow out (horizontally) on a table, then pick the simplest flow from A to B. That’s my first user story. My first ‘horizontal’ slice. This slice might be building a simple, un-styled search box, displaying a plain list of results on the map. (Additional ‘horizontal’ slices may involve filtering results, sorting, pagination, calls to action on search results, etc).

      In considering _HOW_ the team would build this, then I absolutely agree that the matter should be thought of as a vertical topic, when it comes to aligning the presentation layer (front-end) with the back-end processes (search, data retrieval, etc) to ensure this happens consistently and efficiently… One team, as opposed to multiple teams, as The Agile Warrior points out in the post you recommend.

      So, I think in looking at any particular story there is need for both mental models.

      What do you think? Does this shed some light on the issue, or is it even more confusing? 🙂

      Will.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s