One of the best things that I found about Agile development is the ability to have a clean prioritized product backlog of user stories. The question arises, as a product owner, how do you split out or break out or split up your user stories so that they are valuable to users and you can meet the rules for the core of Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In the end, you have to have working software, you can’t have that in one sprint all the time, especially if the story is a bit too large for your development team to tackle in one shot. Thus, you have to invest your time in splitting up your user stories.
One of the most powerful skill-sets for a Product Owner and Agile teams is the ability to find slices in every big idea, every feature/function, and every story that will deliver the maximum amount of value and impact for the efforts that are being done.
The 80/20 Rule of Sales & Marketing by Perry Marshall
If we look at the 80/20 Sales and Marketing by Perry Marshall, we find that a lot of our daily lives and the return on value is determined by this principle and a product that is being made is no exception.
In this principle, if you apply it to the Agile Development methodology, 80% of the impactful value will come from 20% of the results.
One objective your team and you should have are to find what 20% of changes will give the most value to a customer.
Working with your Team
When trying to determine a user story if it holds value, you should work with your entire team. Everyone looks at user stories differently and it’s critical to really understand what you’re going to make in your next sprint.
Schedule two or three 1-hour practice sessions over the next week or two. Make sure that you invite the entire team.
Prepare a meeting and look at your backlog. What you want to look over is something you have been struggling over the past several sprints to get completed.
I am going to be assuming that you have been prioritizing your backlog based upon the level of importance already.
Now you can move onto Determining What types of user story you are faced with.
Determining what type of User Story you have using Cynefin:
In order to determine what type of user story you have utilized the Cynefin framework. Yes, this might not be at the core of agile, but this works. The Cynefin frameworks were developed by Dave Snowden and some of his colleagues to describe the different types of problems that could occur.
This is best done when you’re unsure on what type of problem you could be facing. Below is a chart from https://lizkeogh.com/cynefin-for-developers/.
Let’s look at this chart and how it applies to our user stories starting from the bottom right and working our way around counter clockwise:
- Disordered: Yes, it’s not clearly written out, but that’s what the center, that’s where you start. Figure out what domain you’re working on and then go from there.
- Obvious / Simple: You know what the issue is, you and your team have determined that it could be built in one simple sprint. Thus, you can just jump in and do it.
- Complicated: First find all of the user stories that could be involved. Prioritize what is the most valuable and /or the riskiest first.
- Complex: This is where agile truly shines. You don’t want to try to knock out all of these in one user story. Break these out. You won’t find all of the user stories here in one shot, so try to break out one to two of these and get really good value. Yes, you will have to learn as you go.
- Chaotic: This is the time when there are fires. You might want to back away from new features and functions. I’ve dealt with this a lot, especially when you’re taking over a product and there’s simply chaos. The best thing to do is take a step back, and prioritize the fires and go from there. Once it looks manageable, then work on new user stories.
What is classified as a Good User Story?
I know it can be difficult on finding Good user stories, so what determines a “Good User Story”? Personally, I like to follow Bill Wake’s, INVEST model. INVEST stands for:
Independent: Stories are easiest to work with if they are “independent”, in other words, you have the ability to be flexible and put them in various orders, without relying on another system to work.
Negotiable: It is not an explicit contract for a feature; rather details will be co-created by the customer and programmer during development. The user story has to capture the overall essence and not the details. Why? Have you ever had a customer change their minds while you’re developing? This goes back to the core of the Agile Manifesto.
Valuable: There needs to be value to the customer. Obviously, developers may have their concerns on how the customer is thinking, but these need to be discussed so that it has the customer’s perspective in place.
According to Bill Wakes:
“This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”), but a full database layer (for example) has little value to the customer if there’s no presentation layer.”
Estimable: Has any customer ever asked you “so, when will this be done?”. This is literally one of the things I love about Agile. Yes, everything is in Story Points, but you will be able to give some form of estimate when something can be completed. Why? Your team will be able to tell you and fully understand the details.
Small: A good user story is small enough to be able to be completed within a few weeks. Essentially, it’s a few person-weeks worth of work.
Testable: Writing a story builds an implicit promise. Testability brings a level of clarity to the user story from both the perspective of the customer and the team. Think of the promise in this sense, if the user story isn’t right, then you will have issues testing it. If your team goes through it while they are making the system and it doesn’t pass the “Testable” story, then your team might not be making it right.
One way to classify your story is to look at it from an architectural standpoint. In this methodology, you could look at it as one story for UI / UX (yes, they are two different things), another for databases. Doing it this way does work for small, negotiable and estimable, but it truly fails at being valuable and independent.
How Small Should your User Story Be?
This is a tough question to be answered. User stories should be roughly 6 to 10 stories per iteration, but how small they should really depend upon your team’s velocity. During your sprint planning meeting, your team needs to let you know how many points something needs to be in order to be covered within the sprint. Doing this enough times will help you understand and the team plan out. The goal is to continually improve so that you have better estimates of story points and velocity.
Horizontal Split VS Vertical Split
Broadly speaking, there are two approaches for breaking up large user stories. The first approach is called horizontal splitting and involves breaking up user stories by the kind of work that needs to be done or the application layers that are involved.
As a product owner, you have to understand that there are multiple layers of the entire software that you are working on. There is UI, databases, a front-end, a back-end and testing is split up into groups of tasks.
This is typically how teams work in a more traditional (waterfall) development context. Although this approach has its use in waterfall development, it is most certainly not recommended for breaking up user stories when doing sprints.
Reasons not to do Horizontal Splits for User Stories:
- Individual items do not deliver business value:
- Increases bottlenecks, instead of reducing them
- Horizontal slices can’t be prioritized:
Thus, a horizontal splitting of user stories may actually result in smaller items, but this does severely limit the ability for a team to deliver business value, creates bottlenecks and difficulties in prioritizing work.
Vertical slices are one way to look at your entire system. Doing a vertical slice allows you make a considerable and valuable change in one shot. If a user story is split vertically, it is split in such a manner that the smaller items still generate some business value. The functionality will not be split across technical layers or tasks but across functional layers.
Patterns for splitting User stories / Decompressing User Stories
There are a lot of patterns out there that help you split user stories. Here are 10 of them that I have used and feel that could be the most valuable to you as a Product Owner or Scrum Master. You want to ensure two things;
- Follow the 80/20 principle: Find the most valuable user story comes from a small share of functionalities. Go with the split that lets you toss out low-value functions.
- Choose a split that will get you more equally sized small stories. It might be difficult, but you want to have a nice consistency on your splits which will allow for a good velocity and will provide consistent value.
Strategies & Patterns for Splitting User Stories
Strategy 1: The 80/20 split
– I use it a bit and I feel that it actually has a lot of value for what it is. It utilizes Perry Marshall’s methodology of finding the most value in a product or service. I also found that it does make it easy to classify which Cynefin framework you fall into. Click on this link to download a copy. Also, thanks to the guys at AgileforAll.com for this awesome chart!
Strategy 2: Split by Workflow Steps:
If a user story utilizes a workflow, then the item typically can be broken up into smaller steps. For example, let’s look as a user story for ordering process on an e-commerce site:
Story: As a customer, I would like to purchase the goods in an eCommerce store in my shopping cart and have them delivered to my home.
This sounds like a fairly good process that needs to be built out:
- As a customer, I want to log in with my account so I don’t have to re-enter my information every time.
- As a customer, I want to review and confirm my order, so I can fix any mistakes before I pay.
- As a customer, I want to be able to pay for my order using my credit card and confirm my payment has been processed.
- As a customer, I want to receive an email confirmation with my order, so I have proof of my purchase.
By breaking up larger user stories like this, there can be a nice methodology built into the flow of how processes can work. A lot of times you will find that there are many redundant steps and you can eliminate them and actually improve your UX at the same time.
Strategy 3: Crud Methodology:
What is the CRUD method? It’s not when you’re in trouble, methodology. It stands for:
This typically works in such a manner, As IT professionals, we often see Create, Read, Update, and Delete operations in our user stories. This strategy can typically be used when a user story has the word “manage” in it. For example,
As an online shopper, I want to be able to manage my user profile, so that I can view and update my account details and settings
How does this method break down such a user story?
- As an online shopper, I want to create an account so that I can make online purchases
- …I want to view my account
- …I want to update my account details
- …I want to cancel my account
Strategy 4: Hamburger methodology:
I personally love this methodology, it works really well (it also makes me a bit hungry).
Ideally, the Hamburger Methodology works in any of the below scenarios:
- The story is too big to split up
- The delivery team is a bit inexperienced to do a proper breakdown and thinks only about the technical aspects
- This is a new project and there are no simple user stories to work with
- The business users will not accept any breakdown that is proposed by the delivery team.
Step 1: Identify Tasks
Determine the technical steps that would be involved in implementing the story from a high-level perspective. Make sure that you break the story down into the technical components and using a workflow method mixed in here works as well. The key here is to ensure that the tasks involved become the center of the burger.
Step 2: Identify Options for Tasks
Break up the teams and ask them to define what the quality for each task and what would give some serious value to that task for the user. Have the team write down several options on different levels of quality on post-it notes.
Step 3: Combine the Results
Now is the time to get all of the results from your team members and put the burger together. Have a representative from each team bring up the post-it notes and fill in the layers of the hamburger and have them briefly introduce each of the notes. Identify duplicates and toss them out.
In order to identify the quality requirements, align the most important from left to right.
Step 4: Trim Out the Excess
As a group, go through the tasks and really compare the lowest quality options with the things next to them. This might get a bit hairy, depending on the viewpoints of the team, so this will take a bit of time to do. Try to break down some similar sized items so that they are a bit more manageable inside of a single sprint.
Step 5: The First Bite
Now that you have your juicy burger ready to go, take the first bite. Ensure that you discuss what the minimum acceptance level of quality is for each step, remember this focus’s around the quality.
Step 6: Take another bite…and keep going
There is always room for improvements. No matter where you’re at you should always try to continue to improve. It’s always good to use complexity comparisons between tasks in order to determine how much the next bite should be.
Note: The photos are for the Hamburger methodology are from https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/
Strategy 5: Business Rule Variations
Yes, we are focused on the user in this, but these revolve around business logic as well.
Let’s go back to our eCommerce site’s user story:
“As a customer, I want to purchase the good in my shopping basket so that I can receive my products at home”
When it comes to business rule variations these have some logic rules that need to be implemented. Here are some examples:
- As a shop owner, I don’t want order over a certain dollar value to be able to be purchased.
- As a shop owner, I want to decline non-US based customers
- As a shop owner, I want orders that not paid for to be canceled within 48 hours.
Strategy 6: Major Effort
There are times where a user story can be split into several parts where the most effort can go into implementing the first part. Here’s an example:
As a user, I can pay for my order with VISA, Mastercard, Diners Club, or AMEX
This could be split into four separate stories, one for each card type. The credit card processing infrastructure will be built to support the first story; adding more credit card types will fairly easy once the core system is built. We could estimate the first story to be larger than the other three, but then we will have to change the estimates if the Product Owner changes the priorities. The best way to do this is to defer the decision about which card type gets implement:
…I can pay with one credit card type (VISA)
…I can pay with all four credit card types (VISA, MC, DC, AMEX)
Yes, they are not independent, but the dependencies are a bit clearer than they would have been with a separate story for each card type.
No matter what your goals are there are a lot of ways to break out your user stories. Always remember that there’s more than one methodology out there to help you succeed at finding what user story splitting method will work for you.
I hope you found this blog helpful. Please take a few moments and share this with your friends & colleagues.