Properly breaking down Product Backlog Items (PBIs) into smaller items is an essential skill for Scrum team to succeed in software development. Some Product Backlog Items in a backlog will require more effort than expected, while other items will require less. So if the work for a sprint contains only a few large items, the impact of underestimating the work on even a single item will have a profound impact on the sprint. And since larger items tend to be harder to estimate and understand, the potential for a failed sprint increases further.
Experienced Scrum Teams spend time and effort to break down large PBIs into smaller stories when they are planning a new sprint. This process of breaking down work improves shared understanding, increases the accuracy of estimation and facilitates the Product Owner in the prioritization of work. it isn’t easy to do well, and takes practice to do it properly and efficiently.
General speaking, there are two approaches for breaking up large PBIs. The first approach is called ‘horizontal break-down’, and involves breaking down stories by the kind of work that needs to be done, or the layers or components that are involved. So, work that has to be done for the UI, the database, some component, a front-end and testing are split up into technical items on the Backlog.
This doesn’t work well in Scrum for several reasons:
- Individual items do not result in working, demonstrable, software: Suppose that a team works on an order process for a webshop in a sprint. If they would split up the PBI horizontally, they would end up with work for design, database, front-end and testing. Although the items are certainly smaller, they don’t deliver working software on their own. After all, a new bit of functionality can’t go live when only the UI is finished, or when only the database was modified. It is also a bad idea to go live without sufficient testing. So, individual items do not result in working, demonstrable, software and — by extension — business value. Only the combination of all the work generates business value. But only if all the tasks are completed. And this is often a problem, as the next bullet explains;
- 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 or working software on their own, a Product Owner will be unable to prioritize work. There is also a good chance that the slices will be fairly technical, which creates distance and misunderstanding between the Product Owner and the team;
Although a horizontal break-down of PBIs will result in smaller items, it severely limits the ability of a team to deliver working software, work around bottlenecks and prioritize work. It therefore increases the risk of failing the sprint.
In Scrum, a vertical break-down is more useful, in which PBI’s are broken down into smaller PBI’s (instead of technical tasks). If PBI’s are broken down vertically, they are broken down in such a way that smaller items still result in working, demonstrable, software. Functionality will not be split across technical layers or tasks, but across functional layers. So, if the PBI is ‘As customer I can pay for my order, so I can get my products’, it can be broken down into smaller PBI’s like ‘As customer I can pay by wire transfer, so I can get my products’ or ‘As customer I can pay with credit card, so I can get my products’.
When a large PBI is vertically broken down into very small pieces, a lot of cool agile magic happens.
- The smaller slices are much easier to understand, so there is less likelihood of a lack of consensus between team members.
- The small size also tends to make estimates more accurate, if your team is estimating these slices.
- Smaller slices give us a faster feedback loop – we find defects in design, usability, code, and integration faster. We can get them to users sooner for their feedback. Small slices allow the team to get small wins on an almost daily basis, leading to greater engagement.
- If your team has specialized people on it (testers, DB people, etc.), they’re not sitting around waiting while a bunch of work is done in a previous step – since the slices are small, little pieces of work are flowing through the system quickly.
- Your daily scrums become far more interesting and useful. Instead of “yeah, I’m 20% done adding all of the new schema to the DB”, you get “we got the time stamps working in the UI, and today we’re going to make the data persist when we go offline”.
There are many strategies available for breaking down large PBI’s, these strategies not only help in breaking down PBI’s, 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 Scrum Team should spend time on.