How to Best Slice User Stories

Thanks to Ben Godwin for a great email question that prompted this post!  If you have your own questions about agile and don't know where to turn, drop me a line for some free advice.

Learning to split large user stories into smaller user stories is one of the best things a team can do to improve their scrum workflow.  Not only are smaller stories easier to understand and therefore easier to estimate, but their smaller size makes them inherently less risky for a team to take on.

However, when teams first start splitting stories they’re often tempted to split them horizontally rather than vertically.  To understand what I mean by this, let’s take a look at an example.

Imagine that you had a story to allow a salesperson to log into a sales management application.  The story may look something like this…

“As a salesperson, I would like to log into my sales management application, so I can enter my lead information.”

At first glance this story may look pretty simple.  However, as we start to unpack it we realize there are a few additional concerns here that we may not have thought of originally.  For example, what feedback will we give the user when they enter an incorrect password, or how many times can a user enter an incorrect password before their account is locked?

After these additional concerns have come to light this story may become too large of a story for a team to feel comfortable tackling.  Instead, they may decide to slice it into smaller stories that can be tackled one at a time.

Slicing User Stories Horizontally

In their first attempt at slicing, most teams will try to slice the story horizontally...or across architectural lines.  This might result in new stories that look like this…

• Create a user interface with a username and password field that shows validation errors when the user enters an incorrect password or locks their account.

• Implement the server side logic to validate the user's password and to keep track of how many successive incorrect login attempts the user has made.

• Update the user record in the DB.  For example, update the last login date on a successful login or lock the account if the user makes three incorrect attempts.

In the image on the right, we can imagine that the slice of cake represents the complete story of a salesperson logging into the application.  Each layer of the cake represents a corresponding architectural layer, from the user interface to the database.

Each rectangle overlaid on the image represents one of the story slices from above.  For example, the orange rectangle may represent the story to create the user interface while the yellow rectangle represents the story to implement the database changes.

Slicing stories horizontally is always a nice place for teams to start because it feels familiar to how developers think.  This is because we tend to decompose problems into technical layers.  However, it also mimics the structure of teams that have come from a more traditional environment.  Many teams are used to working in more siloed environments where they're split amongst a database team, a UI team, and a server team each of which is responsible for their own tasks.  Even when we break down the silos and bring those people together as part of a scrum team many of us still tend to decompose the tasks in the same way.

However, as easy as horizontal story slicing is to get started with it’s not without its drawbacks.  The biggest being that it encourages developers to specialize which lowers your bus factor.  It can also lead to the development team avoiding certain stories or leaving them to the end if they demand a skillset that none of the team feels confident with.  For example, if your team is composed entirely of strong server side developers with little experience on the user interface side then the story above about creating a user interface will likely be avoided by most team members.  Since no one on the team is particularly strong in this skill leaving this story until the end of the sprint makes an already risky proposition even riskier.

Slicing User Stories Vertically

The alternative to this is to slice the stories vertically.  This means that each story crosses all boundaries of the architecture but implements only a sliver a functionality each time.

Returning to our login example, if we slice the story vertically the new stories may look like this...

• Add the ability for a user to login with a correct password.Includes adding the username and password fields to the user interface, implementing the happy path server side logic, and updating the last login field on the database record.

• Prevent the user from logging in with an incorrect password.
  Updates the user interface to provide an incorrect password validation message and adds a negative path to the server side logic.

• Lock the user's account after 3 incorrect attempts.
  Updates the user interface to provide a locked account validation message, tracks the number of failed logins either on the server side or in the database, and updates the database record to be locked.

Returning to our cake analogy from before, we now overlay each rectangle vertically so each rectangle represents a story sliced vertically through the entire architecture.  For example, the orange rectangle may represent the story allowing the user to login with a correct password while the light yellow rectangle may represent the story which locks the account after 3 incorrect attempts.

The advantage to slicing our stories vertically is that each resulting story still provides some sort of meaningful value to the user.  This not only makes them easier to test, but they also become easier for the customer to interact with to provide feedback and guidance for our next sprint.  A customer can provide direction based on their experience with a partially completed login form, but they can’t with only a set of database tables.

Along these same lines, vertically sliced stories also tend to ease the pain when not we’re not able to complete all stories we planned on during a sprint.  In the example above, imagine that we completed the first two stories: allowing the user to login with a correct password but preventing them from doing so with an incorrect password.  However, we were unable to complete the final story which would lock the user’s account after 3 incorrect attempts.  It will be easy for a customer to understand the portion of the work completed versus the portion that’s not when it’s demoed to them.  This would not be the case with horizontally split stories where we had completed the server side logic to validate the user’s password as well as the corresponding database updates, but still had yet to complete the associated UI story.

This Won't Be Easy

Slicing stories vertically is consistently one of the toughest mind shifts for a team new to agile to make.  One reason is that this tends to lead to stories that are more complex and therefore a little tougher to estimate.  It also pushes some developers out of their comfort zone.  For example, if a particular developer is an incredibly strong server side developer but doesn't like to deal with UI issues then they're not going to feel comfortable estimating a story that includes UI work.  In fact, they may not even want to work on it when it comes up in the sprint.

But, if you can get over the initial hump, this technique actually has a lot of advantages.  One of the biggest is that it forces developers to get better at skills they may have been able to avoid in the past, which raises your bus factor.  For example, you're no longer in as much trouble if the "user interface guy" suddenly gets the flu the week before a big deadline.

Another advantage is that it teaches developers to think of features holistically rather than just in architectural slices.  The result is that while at the beginning the estimates may suffer, as the team gets better at thinking about each feature as a whole you'll start to get more accurate estimates over the long run since the team has a greater appreciation for a new feature's impact across the entire system.

Finally, delivering stories which slice through all layers of the architecture tends to make them more complete and therefore easier to test.  This means that you can get feedback on your features even sooner which, in the end, is the real goal.