How To Break Down Product Backlog Items in Scrum? Options

codeling Posts: 1153 Points: 4845
Posted: Friday, March 29, 2019 11:11:12 AM

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.

horizontal-slice

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 vartiically 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.


codeling Posts: 1153 Points: 4845
Posted: Friday, March 29, 2019 2:07:23 PM

Breaking down by workflows

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:

  • As customer I can log-in with my account, so I don’t have to re-enter my personal — information every time;
  • As customer I can review and confirm my order, so I can correct mistakes before I pay;
  • As customer I can pay for my order with a wire transfer, so that I can confirm my order;
  • As customer I can pay for my order with credit card, so that I can confirm my order;
  • As customer I receive a confirmation email with my order, so I have proof of my purchase;

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.


codeling Posts: 1153 Points: 4845
Posted: Friday, March 29, 2019 2:10:07 PM

Breaking down by workflows

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:

  1. Manager assigns task to worker
  2. Worker sees message that a new task is assigned to them
  3. Worker can choose to Accept task or Decline task
  4. If Accept, task is added to their work queue
  5. If Declined, worker is prompted to provide reason for declining
  6. Manager receives message that worker accepted or declined, with reason if decline

codeling Posts: 1153 Points: 4845
Posted: Friday, March 29, 2019 2:32:02 PM

Breaking down by workflows: scucess flow and alternative flows

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:

  • As user I can log in with my account, so that I can access secure pages (scucess);
  • As user I am able to reset my password when my login fails, so I can try to log in again (alternative);
  • As user I am given the option to register a new account if my login is not known, so I can gain access to secure pages (alternative);
  • As site owner I can block users that log in incorrectly three times in a row, so I can protect the site against hackers (unhalternative);

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.

Users browsing this topic
Guest