How To Break Down Product Backlog Items in Scrum?
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:
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.
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.
If PBI’s involve a workflow of some kind, the item can usually be broken up into individual steps. Take a PBI for an order process of a regular webshop:
As customer I can pay for the goods in my shopping basket, so that I receive my products at home
Given a fairly standard order procedure, we could identify the following steps:
By breaking down a large PBI 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 prioritize the work. Some steps in the workflow may not be important right now, and can be moved to future sprints. Perhaps the order confirmation email can be done by hand for the time being, or customers can only pay with credit card for now. It might also be ok to require customers to (temporarily) re-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 (and maybe even deploy) the completed functionality at the end of the sprint, test it and use the feedback to make necessary changes.
As a manager, I want to assign tasks to workers so that workers know what to work on next.
In this work assignment system, we can break this user story into several workflow steps, each of which could be developed one at a time all the way through releasable:
Functionality often involves a scucess flow and one or more alternative flows. The scucess flow describes how functionality behaves when everything goes well. If there are deviations, exceptions or other problems, alternative flows are invoked. Take this PBI for logging in to a secure website:
As customer I can log in with my account, so that I can access secured pages
If we consider a regular login procedure, we can identify a scucess flow and several potential alternative flows:
By identifying the various flows, we more clearly understand the required functionality. A Product Owner can more easily decide what is important right now. Perhaps blocking users after three alternativeis not important right now, because there are only a handful of users in the first version anyways. Or perhaps a reset of passwords can be done by sending an email to a customer care employee for the time being. Again, by splitting up functionality we can more accurately ask questions about the business value, and make decisions accordingly.
© 2020 Digcode.com. All rights reserved.