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 Small should Items 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. “
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 by customers. Items that can help us in getting the true feedback.
Five Ways To Split Product Backlog Items
Product Backlog Items (PBI) are 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 could also be used by 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:
- As an Online Customer, I want to view my Shopping Basket, So That I can check the quantity and amount before checkout.
- 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 could offer value to businesses as well.
For example, I was 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 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 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 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 What Records can only be updated by HR Admins
- Delete An Existing Employee Record: Who can delete that, what happens when a record is 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 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 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
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 are 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 avoiding any confusion regarding tax liabilities.
Job Story for VAT Customers
- When I am reviewing my company’s purchases and preparing for tax submissions,
- I want to receive invoices that include a comprehensive breakdown of VAT charges,
- So I can accurately calculate and 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 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 let your product backlog be the beacon that guides your agile journey to success.
I can help!
📅My upcoming class schedule is👉 here
🏢 More than 5 people, why not take advantage of learning with people from your organisation? Learn more about Private Training 👉 here
🔔Why Not Subscribe To My Newsletter 'Vison To Value' where I share weekly nano-tips to deliver value to users, teams and organisations?
