Back to Ask the Authors

Q: Is there any way of splitting the user stories vertically in smaller splits? I have tried doing this in my team many times, but always ended up in the horizontal slices only.

Author Darrell Rigby responds: Thank you for raising an important issue that plagues so many Agile teams—though few even know it.

For those who are not (yet) familiar with the challenge, it goes like this. When we launch an Agile team, we give it a mission. That mission describes a user story (that is, a customer problem for the team to solve) rather than a predetermined set of features and functions to build. This way, the team constantly focuses on creating real value for real customers. An effective user story often uses a simple template:

• As a <type of customer>
• I want <desired solutions and experiences>
• So that I can achieve <customer goals, functional and emotional benefits>

Good user stories provide valuable focus for Agile teams, but big ones may require months or years to accomplish. So how can teams break them into smaller pieces to tackle in sprints that run for a week or two?

Horizontal slices break the story into component layers. Vertical slices break the big user story into smaller user stories. Consider the example below of an online cosmetics retailer trying to improve its online shopping experience (see Figure). They promote sales with a lot of free samples and coupons, which they know causes serious customer confusion, but should they fix the entire database layer for all customer experiences first or focus on fixing only one slice of the customer experience (select and pay) first?

Figure 1: Breaking user stories into vertical slices is more Agile

Whenever possible, use vertical slicing—keeping teams focused on customer missions, creating integrated solutions that make all components work seamlessly together and frequently releasing innovations that noticeably improve actual customer experiences.

Use the same template for slicing that we use for creating the original user story. For example:

• As a <teenage girl with limited income>
• I want <a simple way to load all of my coupons and discounts>
• So that I can <be confident I am quickly and easily getting the best deal possible>

It’s hard to imagine a teenager asking for a better database, and it’s nearly impossible to test a minimum viable database prototype to see if it changes this customer’s behaviors and improves business outcomes.