Please note: A revised and extended version of this post can be found here.
I recently coached a team that ran into problems because the user stories in their sprint turned out to be too big. This inspired me to create a cheatsheet (pdf) with 8 common Agile strategies for splitting up user stories. During the next sprint planning session, the team successfully managed to split large user stories into smaller ones and helped the product owner prioritize them. In this post, I want to share the cheatsheet and extend it with some background and additional examples. Hopefully, you can apply these strategies during sprint planning or backlog grooming sessions.
Experienced Scrum Teams prefer sprint backlogs with many small user stories instead of just a few large items. They have learned from experience that smaller user stories improve the flow in a sprint, make for a smoother burndown and reduce the risk of failing the sprint. After all, software development is an unpredictable business. Some user stories require more time and effort than expected, while others require less. If a team under anticipated the work of a single item, the impact on the sprint will be more severe if it contains only a few items. Larger items also tend to be harder to estimate, which further increases risk. Therefore, experienced Scrum Teams consciously split up large user stories into (much) smaller ones to improve understanding, increase the accuracy of estimation and make it easier for the product owner to prioritize the work. This is not easy, and takes quite a bit of practice to do this 'on the fly'. Thankfully, the Scrum and Agile communities have devised a number of useful strategies for breaking down functionality into smaller bits. These strategies are intended to be used during sprint planning or when grooming the backlog, without requiring exhausting and time-consuming analyses phases.
Horizontal versus vertical splitting?
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. So, work that has to be done for the 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 Scrumming. There are a number of reasons:**
- Individual items do not deliver business value: Suppose that a team works on an order process for a webshop in a sprint. If they would split up the work horizontally, they would end up with work for design, database, front-end and testing. Although the items are certainly smaller, they don't deliver any business value separately. After all, a product owner cannot go live when only the UI is finished, or when the database is set up. It is not adviseable to go live when the team did not have sufficient time to go through the items concerned with testing. So, individual items do not deliver business value. The combination of all the work done in the sprint does generate business value, but only if all the tasks have been completed. But this is often a problem, as the next problem explains;
- Increases bottlenecks, instead of reducing them: Horizontal splitting is often accompanied by so-called 'silo thinking'. Every member is taken from one of the silos required for software development. The 'design guy' will take care of design, the 'database guy' will set up the database, the 'developer' writes the code and the 'tester' does the testing. If team members are not interchangeable (which is often the case when using this approach) there is a good chance of bottlenecks. If the 'design guy' can't get his work done on time, this will impact the tasks that follow the design. Because team members can't help each other out, every delay, problem or interruption will impact the entire sprint. And this will happen;
- Horizontal slices can't be prioritized: How can a product owner prioritize a backlog if it consists of horizontal slices? Because none of the items deliver business value in themselves, a product owner will be unable to prioritize the work. There is also a good chance that the slices will be fairly technical, which makes it even harder and creates distance and misunderstanding between the product owner and the team;
So, horizontal splitting of user stories may result in smaller items, but severley limits the ability of a team to deliver business value, work around bottlenecks and prioritize work. It increases the risk of failing the sprint. In Scrum (and I would say in general), vertical splitting is more useful. 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. So, if the user story is 'As customer I want to pay for my order, so I can get my products', it can, for example, be split into smaller user stories like 'As customer I want to pay by wire transfer, so I can get my products' or 'As customer I want to pay with my creditcard, so I can get my products'.
An easy way to understand the difference is to use a metaphore. Imagine cutting a cake with layers of cream, fruit and cake. If you would cut a cake horizontally, every guest would just get a slice of cake, cream or fruit. I'm sure that your guests would've expected something else. Getting just a single layer of cake does not allow them to sample (review) the entire cake. An approach that is more friendly for your guests is to create vertical slices. Everyone gets a slice of cake, with a piece of all the layers:!
There are many strategies available for breaking up large user stories. I have collected eight of the most useful ones. You can download a cheatsheet at the bottom of this page. As you will see, all these strategies not only help in breaking down user stories, they also help in deciding what is important and what is not. This way, the product owner can more easily prioritize the work and make more informed decisions on what the development team should spend it's time on. In that sense, t helps a team to think pragmatically:
Strategy 1: Split by workflow steps
If user stories involve a workflow of some kind, the item can usually be broken up into individual steps. Take a user story for an order process of a regular webshop:
As customer I want to purchase the goods in my shopping basket so that I can receive my products at home
Given a fairly standard order procedure, we could identify the following steps:
- As customer I want to log in with my account so I don't have to re-enter my personal information every time;
- As customer I want to review and confirm my order, so I can correct mistakes before I pay;
- As customer I want to pay for my order with a wire transfer, so that I can confirm my order;
- As customer I want to pay for my order with creditcard, so that I can confirm my order;
- As customer I want to receive a confirmation e-mail with my order, so I have proof of my purchase;
By breaking up a large user story like this, we have improved our understanding of the functionality and our ability to estimate. It will also be easier for a product owner to make decisions about priority. Some workflow steps may not be important right now and can be moved to future sprints. Perhaps the order confirmation mail can be done by hand for the time being, customers can only pay with credit card for now, or customers are temporarily required to enter their personal information for every order. This will certainly limit the functionality of the webshop, but it does allow a Scrum Team to review the completed functionality at the end of the sprint, test it (perhaps by going live) and use the feedback to make necessary changes.
Strategy 2: Split by business rules
Many user stories involve a number of explicit or implicit business rules. Take this user story, again for the order process of a regular webshop:
As customer I want to purchase the goods in my shopping basket so that I can receive my products at home
Given a fairly standard order procedure, we could identify the following 'business rules' that underly this process:
- As shop owner I want to decline orders below 10 dollars, because I don't make any profit on them;
- As shop owner I want to decline customers from outside the US, because the shipping expenses make these orders unprofitable;
- As shop owner I want to reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
- As shop owner I want to automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers;
Business rules are often implicit, so it will take some skill to unearth them. It may help to a strategy described below (#7); how is the functionality going to be tested? Often, the test cases imply important business rules. Once the business rules have been identified, it will have improved our understanding and ability to estimate. The product owner may decide that some business rules are not important for now, or can be implemented in a simplified form. Perhaps it's ok for now to manually return unpaid products to stock when a payment has not been received within 48 hours, or orders can be cancelled manually. Even more pragmatically, a message on the site explaining that 'orders are not shipped outside the US' or that 'the minimum order price has to be at least 10 dollars' may be sufficient for now. It will save time and money required to enforce this business rule.
Strategy 3: Split by happy / unhappy flow
Functionality often involves a happy flow and one or more unhappy flows. The happy flow describes how functionality behaves when everything goes well. If there a deviations, exceptions or other problems, unhappy flows are invoked. Take this user story for logging in to a secure website:
As customer I want to log in with my account so that I can access secured pages;
If we consider a regular login procedure, we can identify a happy flow and several potential unhappy flows:
- As user I want to log in with my account, so that I can access secure pages (happy);
- As user I want to be able to reset my password when my login fails, so I can try to log in again (unhappy);
- As user I want to be given the option to register a new account if my login is not known, so I can gain access to secure pages (unhappy);
- As site owner I want to block users that log in incorrectly three times in a row, so I can protect the site against hackers (unhappy);
Unhappy flows describe exceptions. By identifying the various flows, we more clearly understand the required functionality. A product owner can also more easily decide what is important right now. Perhaps blocking users after three failures is not important because there are only a handful of users in the first version. Or perhaps a reset of passwords can be done by sending an e-mail to a support employee for the time being. Again, by splitting up functionality we can more accurately ask questions about the business value, and make decisions accordingly.
Strategy 4: Split by input options / platform
Many web applications have to support various input options and/or platforms, like desktops, tablets, mobile phones or touchscreens. It may be beneficial to break up large items by their input options. Take a digital Scrum Board for a team:
As team member I want to view the Scrum Board, so I know the status of the sprint
If we consider a common order process in a webshop, we can identify the following steps:
- As team member I want to view the Scrum Board on my desktop, so I know the status of the sprint;
- As team member I want to view the Scrum Board on my mobile phone, so I know the status of the sprint;
- As team member I want to view the Scrum Board on a touchscreen, so I know the status of the sprint;
- As team member I want to view the Scrum Board on a printout, so I know the status of the sprint;
By splitting up large items like this, the product owner can more easily prioritize which input options or platforms are more important. It's probable that a desktop version is sufficient for now, while a mobile version is pushed to a future sprint. Or perhaps the printout can be implemented with a simple PDF capture of the board for now, without having to create a version specifically suited for print.
Strategy 5: Split by datatypes or parameters
Some user stories can be split based on the datatypes they return or the parameters they are supposed to handle. Take, for example, a search function for a webshop:
As customer I want to search for products so I can view and order them;
There are many ways to search for a product. All these potential parameters can be considered and broken up into smaller user stories:
- As customer I want to search for a product by it's product number, so I can quickly find a product that I already know;
- As customer I want to search for products in a pricerange, so that the search results are more relevant;
- As customer I want to search for products by their color, so that the search results are more relevant;
- As customer I want to search for products in a productgroup, so that the search results are more relevant;
By breaking up the search functionality, we now more clearly understand what kind of search parameters will be used. This allows us to more accurately estimate the functionality, but it also allows a product owner to make decisions about priority. Maybe paging is not yet relevant because of the small number of products. It might become relevant when the number of products grows. Or maybe some of the search functionality can be implemented in a simplified manner for the time being. Another example of this strategy is when breaking up functionality involving management information based on the returning datatypes. Some of the information can be presented visually in charts or graphs (datatypes), but can also be displayed in a tabular format (datatype) for now. Perhaps the product owner is ok with exporting the data to Excel and manually creating all the graphs and charts there for the time being.
Strategy 6: Split by operations
USer stories often involves a number of default operations, such as Create, Read, Update or Deleted (commonly abbreviated as CRUD). CRUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders:
As shop owner I want to manage products in my webshop, so I can update price and product information if it is changed
By identifying the individual operations required for this functionality, we can derive the following smaller bits of functionality:
- As shop owner I want to add new products, so customers can purchase them;
- As shop owner I want to update existing products, so I can adjust for changes in pricing or product information;
- As shop owner I want to delete products, so I can remove products that I no longer stock;
- As shop owner I want to hide products, so they cannot be sold for the time being;
When presented with this strategy, many teams wonder if the smaller items actually deliver business value. After all, what's the point of only creating entities, when you cannot update or delete them afterwards? But perhaps the product owner has such a limited number of products, that editing or deleting can be done through a database manager directly. Sometimes, an operation can be easily implemented in a simplified form. Deleting a product can be done in two ways; you can completely drop the record and all associated records, or you can 'soft delete' a product. In that case, the product is still in the database, but it is marked as 'deleted'. Sometimes one of these approaches is easier to implement, and can be 'good enough' for now.
Strategy 7: Split by test scenarios / test case
This strategy is useful when it is hard to break down large user stories based on functionality alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios have to be checked in order to know if the functionality works? Take a task planning system:
As manager I want to assign tasks to employees, so the can work on tasks
If we consider this functionality based on potential scenarios, we can break down the item into:
- Test case 1: If an employee is already assigned, he or she cannot be assigned to another task;
- Test case 2: If an employee has reported in sick, he or she should be visually marked so they can be ignored;
- Test case 3: If an employee has reported in sick, he or she cannot be assigned to a task;
- Test case 4: If an employee is not yet assigned, they can be assigned to a task;
- Test case 5: Employees can be assigned with a touchscreen monitor;
This strategy actually helps you apply the other strategies implicitly. By thinking about testing, you automatically end up with a number of business rules (#1, #2, #3 and #4) , (un)happy flows (#1, #2 and #3) and even input options (#5). Sometimes, test scenarios will be very complicated because of the work involved to set up the tests and work through them. If a test scenario is not very common to begin with or does not present a high enough risk, a product owner can decide to skip the functionality for the time being and focus on test scenarios that deliver more value. In other cases, test scenarios can be simplified to cover the most urgent issues. Either way, relevant test scenarios can be easily translated into backlog items and added to the sprint or the backlog.
Strategy 8: Split by roles
User stories often involves a number of roles (or groups) that performs parts of that functionality. Take a user story to publish new articles to a public newspaper website:
As news organization I want to publish new articles on our homepage, so customers have a reason to return periodically
By considering the various roles that are involved, we can break the functionality down into the following bits:
- As customer I want to read a new article, so I can be informed of important events;
- As journalist I want to write an article, so it can be read by our customers;
- As editor I want to review the article before putting it on the site, so that we can prevent typos;
- As admin I want to be able to remove articles from the site, so that we can pull offending articles;
- As customer I want to review and confirm my order, so I can correct mistakes before I pay;
By breaking up functionality into the roles that have to perform bits of that functionality, we more clearly understand what functionality is needed and can more accurately estimate the work involved. Writing user stories is a great way to apply this strategy. It also helps the product owner prioritize. Some roles may be less relevant at the moment, and can be implemented later. Perhaps there is not yet need for an editor. Or the editor can be called by a journalist to check the article manually.
Of course, there are many other strategies that may be helpful when breaking up large user stories. I have listed some of them below, but please feel free to add more in the comments:
- Split items based on identified acceptance criteria. This may seem very obvious, but it's often the easiest and most natural way to split up a story. Mapping out acceptance criteria for a user stories requires similar strategies as the ones described in this post;
- Split items based on the parts that are hard to implement and the parts that are easier. It may be difficult to set up a piece of functionality in a heavily designed UI, but getting it to work with a simple UI may be easy and sufficient for now. Again, it's all about being pragmatic and delivering business value;
- Split items based on external dependencies. Sometimes functionality is dependent on external factors, such as implementing a consumer for a remote webservice (e.g. for electronic payment or connecting to Twitter). This may be difficult, but may not have the highest priority. Or the dependencies can be mocked for the time being;
- Split items based on usability requirements. This includes functionality for paging through a list of records, making a website readable for blind people or people with colorblindness or implementing breadcrumbs;
- Split items based on SEO requirements, such as setting up dedicated landing pages for specific keywords, setting up goals for Google Analytics or setting up XML sitemaps;
- Split items based on browser compatibility. Getting a website to work in Internet Explorer 6 is time-consuming, but is sometimes are requirement (sadly). It may be beneficial to at least consider if support for older browsers can be postponed in favor of newer browsers. In that case, a strategy has to be identified to deal with browsers with older browsers though (like a warning message);
When is a user story small enough?
There are no clear-cut rule on how small a user story should ideally be. This greatly depends on the length of the sprints, the nature of the application and the size of the team. In general, I think it's a good idea to have at least 5 to 10 user stories in a sprint. Some of those can be a bit bigger, with a larger number of smaller items. This gives the team enough flexibility. At NowOnline, we consider a relative estimation of 13 points the maximum. Whenever a story is larger, it is broken up. But this all depends on preferences. Some teams may prefer a cut-off value that is smaller or larger. In any case, a sprint with many small items is always preferable to a sprint with a handful of large items. Make good use of the retrospective to reflect on the burndown and determine if the user stories are perhaps too large or too small.
A note on potential concerns from the Scrum Team
There are some concerns that I often hear from Scrum Teams when they're trying to break up user stories. The first is that teams are worried about the reduced business value of the smaller items. This is a very understandable concern and shows that the team clearly understands that Scrum is about delivering business value every sprint, but also with every single item in the sprint backlog. Of course, smaller items will have reduced business value compared to the larger item. But the primary purpose of breaking down functionality is to reduce risk, increase flow and increase the amount of working functionality that can be reviewed every sprint. The alternative is to keep working with very large chunks of functionality, with all the aforementioned consequences and risks.
Another concern is that breaking up functionality will cause more work instead of less. After all, it's often easier and faster to just keep working on a piece of functionality until it's completely done instead of re-visiting bits and pieces of it throughout the sprints. Although this may be true to some extent, there is good reason not to work like this. In Scrum, we implement a process that is designed to continuously review and test our work and adjust according to the feedback we get. So, the functionality that you may have in mind now may be very different from what will actually be implemented when we use Scrum. Although it may be tempting to keep working on a piece of functionality, there is a good chance that you are wasting your time on functionality that will be changed or dropped anyways.
A final concern is that most teams do not immediately 'get' how to break down functionality. It is not uncommon to run into some resistance as a result. This is understandable; trying out new things is difficult because it makes people feel vulnerable. The best way to deal with this, is to persist and gently coach the team by helping them break up their user stories.
In this post, I emphasized the importance of breaking up large items in your (sprint) backlog. A sprint should preferably consist of many small items instead of a handful of large items. The fewer (and larger) the items in a sprint are, the higher the chance of failing the sprint. I presented 8 well-known strategies used by experienced Scrum and Agile teams. But there are certainly more. So if you have an useful additions, please drop a line in the comments. Good luck!