How To Create Smaller Product Backlog Items 

---

Breaking big product backlog items into smaller ones is an essential skill that all product owners should build. 

In the previous article ‘Benefits Of Smaller Product Backlog Items’, we explored why it is important to slice PBIs into smaller value units. In this article, we will explore How to achieve that. 

---

How Smaller Items Should Be?

As small as possible but still valuable. 

A Product is a vehicle to deliver value and each Product Backlog Item( PBI) should deliver incremental value. “

Scrum Guide-2020

We need to think like a vertical slice like a cake. I can enjoy the cake with even the smallest vertical slice. 

Products are all about delivering value. Delivering value to users and customers and also delivering value to business. 

To deliver this value lots of activities need to happen. If I take a typical example of a software development, this may include 

• Designing the User Experience (UX)
• Creating User Interface (UI)
• Analysing and adding functional and non-functional details 
• Writing Code and doing peer reviews 
• Building Database 
• Validating whether desired functionality is working as expected 
• Deploying the feature to Production, etc.

Many teams sometimes decompose units of value into these tasks and start considering these tasks as product backlog items. PLEASE STOP. 

Yes, these activities are important but they don’t deliver value on their own to users, customers or businesses. 

Product Backlog Items are supposed to be units of value. Items that can be used through customers. Items that can help us in getting the true feedback.

---

Five Ways To Split Product Backlog Items 

Product Backlog Items (PBI) supposed to be units of value i.e. they’re supposed to be tangible items that can be used by customers, and they’re designed to help product development teams in getting genuine feedback.

Let’s discuss how we create small PBIs without compromising value.

---

1. Split By User Roles 

A common way we can split our work is by different User Roles. Different user groups may have different needs or problems and if they do, PBIs should be split with that in mind. 

For example, we are building some E-commerce-related products and a product capability, we are focusing on ‘Shopping Basket’. Let’s call this feature ‘View Basket’

For the basket, customers check the amount and quantity before checkout. However, the “View Basket” capability used through customer service teams who help customers resolve issues during checkout.

In this scenario, both user needs are different and other solutions may exist. This creates an opportunity for product teams to break the “View Basket” product into two PBIs:

1. As an Online Customer, I want to view my Shopping Basket, So That I can check the quantity and amount before checkout. 
2. As a Customer Service Executive, I want to view the Shopping Basket, So That I can help struggling customers during checkout. 

Both PBIs are separate units of value and may have different solutions to meet specific needs. Smaller Yet Valuable.

However, don’t just stop here. Ask questions such as 

• Could there be different kinds of Customers or Users?
• If yes, are there more needs/problems than others?
• Are the ways they interact with our products/systems different?
• ……

---

2. Split By Workflow Steps 

Many user journeys involve multiple steps to take a customer or user from start to end, or as we commonly say “end-to-end journey”. However, we sometimes forget that each of these steps can deliver value to users and customers, and also could offer value to businesses as well.

For example, I involved in building a learning management system (LMS) where a capability we worked on was designed to allow learners to take assessments to validate their learning.

Based on the ‘Split By User Roles’ this could be broken for 

• Trainer/Content Creator Who Is Creating Assessment 
• Learner who is Validating Their Knowledge/Learning 
• Line Managers of Leaner Who Want To Get Notified 

Let’s examine, “Learner who is validating their knowledge or learning”.

Typical Steps in the workflow could be 

• Learner Login To LMS Portal 
• Search For Available Assessment 
• Enrol For Available Assessment 
• Take Assessment 
• Learner Get Results 

All the above deliver value to the user in every step and all these steps could be product backlog items on their own and also potentially further be broken down. Smaller Yet Valuable.

---

3. Split By Operations 

Various actions or operation rules also impact many features. Operation Rules can be applied to the way data or resources are stored and also managed. 

Typical operation rules are 

Create (C): Adding a new record 

Read(R): Retrieving existing record without modifying it 

Update(U): Modifying an existing record

Delete(D): Deleting an existing record 

For example, we’re building a Human Resources (HR) system, so the business operations rules and also policies can help us in breaking down PBIs. Here are examples of questions that can lead to more units of value.

• Create A New Employee Record: Who can do that, how can they do that, are there multiple ways to create the record, can we do bulk creation
• Read An Employee Record: Who can read the employee record, what details can only be seen by Line Managers, What Details Can only be seen by HR Admins
• Update An Existing Employee Record: What roles can update employee records, What records can be updated by Line Managers, and also What Records can only be updated by HR Admins 
• Delete An Existing Employee Record: Who can delete that, what happens when a record deleted

All the above can be a separate PBI and answers to some questions could create more PBIs. Smaller Yet Valuable.

---

4. Split By Scenarios/Use Cases 

Many PBIs I have seen where acceptance criteria are very big and cover multiple scenarios and use cases in one PBI itself. These big PBIs contain opportunities to be further broken down into separate units of value.

For example, we’re building a login capability into a system. This task can be broken down by user roles and also further by scenarios as well. One scenario could be a happy path i.e. Successful login after the right User name and password combination. But there are also multiple happy and also non-happy path scenarios as well.

• User Name Correct But Password Incorrect
• User Name Incorrect but Password Correct
• Forgot Password 
• Multiple Attempts With Incorrect Credentials 
• Remember Me From My Login 
• Login Via My Google Account 
• Login Via My Social Media Accounts 
• Login Via Single Sign On 

Conclusion:

Not all of these will be required in early development. Maybe few are never required. But these are smaller PBIs and it can help Product Owners in prioritising the work better. Smaller Yet Valuable.

5. Split By Business Rules 

Many businesses and Products work under various business rules. These business rules could be implemented separately. Sometimes all these business rules not required to be implemented at the same time. 

For example, a user wants to buy a course from my website www.edgeagility.com. During Checkout, as a VAT-registered business in the UK, I only need to charge VAT if the customers are from the UK. 

This could be broken into 2 PBIs

Job Story for Non-VAT Customers

• When I am reconciling my company’s monthly expenses and updating our financial records,
• I want to receive invoices that clearly indicate no VAT charges are applicable,
• So I can efficiently manage our accounting processes, ensuring accuracy in financial reporting and also avoiding any confusion regarding tax liabilities.

Job Story for VAT Customers

• When I am reviewing my company’s purchases and also preparing for tax submissions,
• I want to receive invoices that include a comprehensive breakdown of VAT charges,
• So I can accurately calculate and also report VAT expenses, ensuring compliance with tax regulations and facilitating streamlined financial auditing.

Smaller Yet Valuable.

[Learn more about Job Stories Here]

Conclusion 

In product development, the art of effectively breaking down Product Backlog Items (PBIs) is not just a skill but a necessity. By dividing larger items into smaller, more manageable chunks, we enhance clarity, and also focus, and facilitate smoother workflow.

The journey through our discussion on breaking down PBIs has revealed key strategies but the key theme was Smaller Yet Valuable.

In essence, mastering the breakdown of PBIs is not just about managing tasks; it’s about empowering teams, enhancing collaboration, and ultimately, delivering exceptional products that stand the test of time and change. So, keep refining, keep iterating, and also let your product backlog be the beacon that guides your agile journey to success.