Based on the Scrum Guide, a Product Backlog is an up-and-coming, systematic list of what is required for improving the quality of a product. Scrum team members know that a Product Backlog is the single source of work to do.

Items in the Product Backlog list that the Scrum Team can do within a single sprint are considered prepared for selection in a Sprint Planning Event. After refining activities, they achieve a level of transparency. Product Backlog breakdown otherwise called Product Backlog refinement involves breaking down and further defining the items in the Product Backlog into smaller and more precise items. This work is done by Scrum teams regularly for the addition of details like size, order and description. However, the attributes generally differ based on the niche of work.

The sizing of items in the Product Backlog is taken care of by developers, who will be handling the actual work. In this process, the product owner might influence the developers. The product owner might do this by aiding the development team with understanding and selecting trade-offs. In some instances, many Scrum teams work on the same product. Even in this case, a single Product Backlog is used for explaining the forthcoming work on the product.

Why and When to Breakdown Product Backlog?

We are here to provide you with details about different Product Backlog breakdown strategies. However, it is better to first understand why and when Product Backlog breaking becomes essential.

In general, it is hard to predict software development. Some items in the Product Backlog will need more effort as compared to what is expected. But, some items need less effort and time. Let us consider that the work for a sprint has only a few large items. In this case, even if a single item is underestimated, it can have an impact on the entire sprint.

As larger items tend to be harder to evaluate and understand, the possibility of a failed sprint will increase further. To avoid this situation, experienced Scrum Teams often recommend spending effort and time to break down larger items in the Product Backlog into smaller stories.  At times, they do this breaking down at the time of planning a new sprint. However, with experience, they learn that this breaking down of items in the Product Backlog should be an ongoing process. Only then, sprints and sprint planning will move on without any issues. 

As and when a sprint is fast-approaching, the Scrum team will begin breaking down the Product Backlog for the next sprint. However, the team will do it in a “just-in-time” manner. Scrum teams do this to make sure that they can spend increasingly lesser time on sprints in the near future.

Breaking down Product Backlog is important as it improves shared understanding. It even helps product owners with work prioritization. However, it is not easy to do breakdown a Product Backlog. It needs a lot of practice. However, experts in the Agile community like Mike Cohn, Richard Lawrence, and Dean Leffingwell have devised many useful strategies to break down work into tiny pieces.

Product Backlog Breakdown Strategies:

So, with the importance of breaking down, Product Backlog understood, you will be wondering about the types of Product Backlog breakdown strategies available. Here are a few of them for your understanding:

1. Breaking Down with the Help of Workflow Steps:

In case, a Product Backlog requires a workflow, it is possible to divide it into individual steps. When teams split down a large Product Backlog item or PBI, it will be possible for them to understand the functionality better. Even, it will help them improve the estimate. Again, the product owner will find it easy to prioritize the work.

When you follow the workflow steps for backlog breakdown, the steps of less importance in the workflow will move to future sprints. Here, it will be possible for the Scrum Team to review the entire functionality when the team gets to the closing point of the sprint and then evaluate it for feedback and making changes.

Gaining Insights:

When the stakeholders and the Scrum Team can jointly spot insights, it will be possible to establish a shared understanding of the work. They can rely on UX Fishbowl and Hypothesis Canvas to do this discovery.

UX Fishbowl:

Expanded as User Experience Fishbowl, it is a liberating structure that permits Scrum Teams to explore how will the implementation of an item in the Product Backlog will look from the perspective of stakeholders. 

The UX Fishbowl has a couple of steps and two groups. These steps are carried out in order and as many times as required. Among the two groups, one group is the Scrum Team and the other is the group of stakeholders. When using this technique, the following things happen:

• Stakeholders are called upon to discuss certain things. They are asked to imagine that a particular feature is already part of the product their organization produces. They are asked how, why and when to use the feature. They are also asked about the steps involved and what makes the feature useful. Also, they are asked about the things that can deter them. During these discussions, the members of the Scrum Team will be present and they will carefully take notes of the thing expressed by the stakeholders and take essential insights.
   
• Following the meeting with the stakeholders, the Scrum team members stay back. Otherwise, a meeting is arranged the following day for formulating follow-up questions based on what they heard from stakeholders. These questions will be used as points to discuss for the next round.

The advantage of this technique is that it opens up chances for the Scrum Teams to break down bigger Product Backlogs into smaller items. When breaking down, they will be particular about bringing value to stakeholders.

2. Breaking Down Based On Business Rules:

One of the popular Product Backlog breakdown strategies is to do the breaking down based on the rules of the business. The items in the Product Backlog always involve many implicit and explicit business rules. 

Let us take the example of a department store. As a customer, a person can buy the goods that he has added to his shopping basket from the store. He pays for the products such that he can get them delivered to his doorstep. But the owner of the store might have already framed certain business rules in place like those below:

• As the owner of the store, I have the right to cancel orders for which I have not received payment within 48 hours. In turn, I can sell the products that a customer has added to his shopping cart to another customer as he has not paid even after 48 hours.
   
• As the store owner, I can reserve the products ordered from stock for 48 hours. By doing this, I can make sure that other customers can get to see realistic stocks.
   
• As the owner of the shop, I have the right to decline customers from outside of a particular region. The reason is that the shipping expenses I will have to bear can make the deal unprofitable for my business. 
   
• Also, I reserve the right not to ship orders less than $10 as shipping will make my business incur more costs.

Rules in businesses are generally implicit. So, it will take some analytical skills to extract them. How the new functionality is going to be tested? In general, test cases denote crucial business rules. Once the rules of businesses are identified, they will again help with improving understanding. 

The product owner might decide that some business rules are not crucial for now or can be implemented in a simple manner. It is fine for now to manually return products that are not paid to stock when payment is yet to be received even after 48 hours in the example above. Otherwise, it is possible to cancel the orders manually. For the rules mentioned above, mentioning on the website about minimum order value required for shipping and orders not shipped outside a particular location may be enough. It will save money and time needed for enforcing this business rule.

3. Breaking Down Based On Unhappy/Happy Flow:

Happy flows denote methods in which the functionality will behave when the project moves on well. On the other hand, unhappy flows show up when there are exceptions, deviations or other issues. By spotting and breaking down the different flows into happy and unhappy ones, the Scrum Team will be in a position to understand the required functionality better. In turn, the product owner will decide what is important and needs to be attended to right away. By splitting functionality into unhappy and happy flows, teams will be in a position to ask about the value of the business to aid them to arrive at better decisions.

Simpliaxis is one of the leading professional certification training providers in the world offering multiple courses related to Agile methodologies. We offer numerous Agile related courses such as Certified ScrumMaster (CSM)® Certification Training, Certified Scrum Product Owner (CSPO)® Certification Training, Certified Scrum Developer (CSD) Certification Training, Agile and Scrum Training, PMI-ACP® Certification Training, Professional Scrum with Kanban™ (PSK) Training, Certified Scrum Professional® - Product Owner (CSP®-PO) Certification Training, Agile Sales Management Training, Behaviour Driven Development (BDD) Training and much more. Simpliaxis delivers training to both individuals and corporate groups through instructor-led classroom and online virtual sessions.

Conclusion:

In addition to these Product Backlog breakdown strategies, organizations can also try using input options/platforms, data kinds of parameters, breaking down by operations, test cases, roles and by browser compatibilities.