Here are some study notes that I created whilst learning more about the Scrum.org Professional Scrum Product Backlog Management Skills (PSPBM Skills) course and assessment. These are shared as a revision resource intended to summarise the key elements.
Product Backlog Ordering
Many techniques can be used to order the contents of a Product Backlog. Here are some commonly used approaches:
- The Kano Model is a framework used to categorise and prioritise features based on their potential to satisfy customers. It differentiates between basic needs, performance needs, and delighters (or exciters).
- MoSCoW: This stands for “Must have”, “Should have”, “Could have”, and “Won’t have”. This technique helps in prioritising PBIs by categorising them based on the products needs and requirements.
- Buy a Feature: This is a collaborative prioritisation technique where stakeholders are given a fixed budget and PBIs are assigned a cost. Stakeholders then “buy” the features they believe are most important.
- Thirty-Five: The Thirty-Five technique is a brainstorming and prioritisation method used to generate and rank ideas in collaborative settings. Cards containing ideas are shared and ranked individually to create an unbiased order.
- 25/10 Crowdsourcing is similar to Thirty-Five and enables rapid idea generation and ordering.
Product Backlog Decomposition Levels
When managing a Product Backlog in Scrum, decomposition refers to the act of breaking down large items into smaller, more manageable parts. Scrum does not prescribe any decomposition levels or hierarchy, although the following are commonly used:
- Epic: Epics are large bodies of work that can be broken down further. Think of them as very large Product Backlog items.
- Feature: Large Product Backlog items (but not as large as Epics). As they are decomposed, they may become many individual Product Backlog items.
- Product Backlog items (PBIs): The only level required by Scrum. Must be small enough to complete in a Sprint to be considered ready.
Although multiple levels of decomposition may look helpful, they often add management overhead. Keep it simple and have the fewest levels possible.
INVEST
Applying the INVEST criteria to PBIs helps the Scrum Team create a well-structured and refined product backlog.
I – Independent: Each PBI should be self-contained and independent of other PBIs.
N – Negotiable: PBIs should be flexible and open to discussion and refinement.
V – Valuable: Each PBI should deliver value to customers of the product.
E – Estimable: Developers should be able to understand enough to estimate the size of the PBI.
S – Small: PBIs should be small enough to be completed within a single Sprint.
T – Testable: PBIs should be defined in a way that makes it clear how they will be tested.
Product Roadmaps
Product roadmaps are high-level plans that outline the goals of a product development initiative. They provide a visual representation of the product’s direction and help stakeholders to understand the product’s vision, strategy, and priorities.
A key difference from traditional project plans is that they are created and visualised in a way that emphasises that they are flexible and adaptable. They are designed to evolve as development progresses and as we learn more about the product and its users.
User Stories
User Stories are one of the most popular ways to document Product Backlog items. They are short, simple descriptions of a feature told from the perspective of the person who desires the new capability. The standard format of a User Story is: “As a [type of user], I want [an action] so that [a benefit or outcome].”
Important Considerations
- Understand who your stakeholders are and what they need. Work with them and support different sub-groups in appropriate ways.
- Understand who your customers and users are and talk to them to validate your assumptions. Identifying Proto-persona types may be helpful.
- Experiment to test your value proposition as you develop your product.
- Working back from a product vision, to a product Goal to Product Backlog items can be helpful to maintain focus and ensure the work of a Scrum Team remains valuable.
- The Sprint Review is a form of Product Backlog refinement. It can help increase the shared understanding of future potential valuable work.
- Scrum requires a Definition of Done, but not a definition of ready. While a definition of ready can be a useful practice, it can delay the realisation of value.
Scrum Guide Essential Extracts
The following is extracted from the Scrum Guide (2020) relating to the Product Backlog and managing and refining it. Please read carefully and notice what it say and does not say!
Product Owner
The Product Owner is also accountable for effective Product Backlog management:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
Decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
Scrum Master
The Scrum Master serves the Product Owner in several ways, including:
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Helping establish empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.
Sprint Review
Attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.
Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
They usually acquire this degree of transparency after refining activities.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing.
--
Hi, my name is Simon Kneafsey and I am a Professional Scrum Trainer with Scrum.org & TheScrumMaster.co.uk. I am on a mission to simplify Scrum for a million people. I have helped over 10,000 people so far and I can help you too.
Learn more at TheScrumMaster.co.uk and signup for our newsletter with 80,000+ practitioners.
