Learning to split large user stories into smaller user stories is one of the best things a team can do to improve their 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.
But when teams first start splitting stories, they’re often tempted to split them horizontally rather than vertically. To understand what I mean, let’s look at an example.
Imagine that you created 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. But as we start to unpack it, we realize that there are a few concerns that we may not have originally thought of. 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 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.
In their first attempt at slicing, most teams will try to slice the story horizontally, or by architectural layers. 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 (e.g., update the last login date on a successful login or lock the account if the user makes three incorrect attempts).”
In the image above, 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 might represent the story to create the user interface, while the yellow rectangle might represent the story to implement the database changes.
Slicing stories horizontally is a nice starting point for teams since it feels familiar to how developers think. This is because we tend to decompose problems into technical layers. But it also mimics the structure of teams that have come from a more traditional environment. Many teams are used to working in 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 individuals together as part of a team, many will still continue to decompose the tasks in the same way.
But even though it’s easy to get started with slicing your stories horizontally, the practice still has its drawbacks. The biggest drawback is that it encourages developers to specialize, which can create silos of knowledge on your team. This can cause problems if one your developers chooses to leave your team. It can also lead to the development team avoiding certain stories or leaving them to the end if they demand a skill set that no one 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 most team members will likely avoid the story above about creating a user interface. 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.
The alternative to this approach is to slice the stories vertically. This means that each story crosses all boundaries of the architecture but implements only a sliver of 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 three 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 that each rectangle represents a story sliced vertically through the entire architecture, as illustrated above. For example, the orange rectangle may represent the story to allow the user to login with a correct password, while the light yellow rectangle may represent the story that locks the account after three incorrect attempts.
The advantage to slicing our stories vertically is that each resulting story still provides some piece of meaningful value to the user. This not only makes them easier to test, but it also becomes easier for the customer to interact with and provide feedback and guidance on each story. This feedback can then be incorporated into the next iteration. For example, a customer can easily provide direction based on their experience with a partially completed login form, but they can’t provide any feedback on only a set of database tables.
Along these same lines, vertically sliced stories also tend to ease the pain when 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 three 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.
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 tougher to estimate. It also pushes some developers out of their comfort zone by asking them to speak to areas of the architecture that they normally don’t interact with. 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 that story when it comes up in the sprint.
But if you can get over the initial learning hump, this technique has a lot of advantages. One of the biggest advantages is that it forces developers to get better at skills they may have been able to avoid in the past, which reduces your risk in the event that one of your key developers is suddenly unavailable. 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, over time as the team gets better at thinking about each feature as a whole, you’ll start to get more accurate estimates since the team will build a greater appreciation for a new feature’s impact across the entire system.
Finally, delivering stories that 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.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
