Scrum is an agile framework to iteratively and incrementally create product features. It starts with a customer-prioritised list of desired product features increments (a Product Backlog) which are periodically – typically a one- or two-weeks period (a Sprint) — added to the product.
All starts with the Product Backlog, although Scrum has no definition of how to build a Backlog. Therefore, these are common questions:
- How to get to a Backlog?
- How to build something that has value?
- How to meet the real customer needs?
- How to define what is priority for the customer at the first moment?
Trying to answer these questions, after many years working within various contexts and organisations, Fabio Aguiar created the “PBB – Product Backlog Building”. PBB’s main objective is to help build a Product Backlog in a collaborative way, based on a shared understanding of the product context and the user needs.
The PBB dynamics consists in constructing the Product Backlog via a facilitation tool, the PBB Canvas. This dynamic brings everyone interested on understanding, planning and prioritising the product features to a hands-on workshop for designing and defining an effective Product Backlog that is fully aligned with the customer needs and the business values.
The PBB main benefits are:
• Assist in building a Product Backlog in an effective and collaborative way.
• Build a shared understanding of the customer’s needs, facilitating the product discovery.
• Describe the user experience and its relation to the product features.
• Facilitate the discovery and the writing of the User Stories.
PBB is achieved by following a few steps to facilitate the understanding of the client needs and the product features context. These steps are represented all in one page, the PBB Canvas.
Following is the PBB Canvas main steps:
1. Contextualize the Product
2. Describe the Personas
3. Understand the Features
4. Map the steps of a Feature
5. Identify the backlog itens
Contextualize the Product
At first, it is important to clarify and understand what the product is. You must understand the problems and the desired state. This will help in understanding the expectations and clarifying the main objectives.
PRODUCT NAME: Identify the product that will be built. Imagine that this product was in a box; what name would be written on the box?
PROBLEMS: Identify and understand the Current State by pointing out a set of problems and pains in the context in question. At this stage, the participants should collaboratively seek the understanding of the current state by describing the problems and the needs. Understanding the problems is essential before working out a solution.
EXPECTATIONS: Identify the Desired State by aligning expectations related to current state problems. Avoid describing the solution in detail on how we will achieve the desired state; instead, list expectations (typically related to elimination or changes to the Current State problems).
Describe the Personas
A persona represents a product user, describing not only the role but also their specific needs. This creates a realistic representation of users, helping the team to describe features from the point of view of who will interact with the final product.
PERSONA: Identify the users, roles and people involved in the product; Describe what they do and expect from the product.
Understand the Features
Feature is a description of a user’s action or interaction with the product. For example: print invoice, view detailed statement, and invite facebook friends. The description of a feature should be as simple as possible. The user is trying to do something. The product must have a feature for it. What feature is this?
Feature Example: Buy Online Product
Ask the following questions for each of the identified personas: What does such persona do? and what does such persona expect? Typically, responses describe the user’s actions or interactions with the product: the features.
FEATURES: Identify the features that each persona performs on the product, organised in sequence of use (from left to right). Describe each feature with a brief description; Next, describe the “Problems” and the “Benefits” related to each feature. Write down the feature’s problems and the feature’s benefits on smaller post-it notes and position on the left and right side of the post-it with the feature description.
Tip: Limit the total number of features to a maximum of 10; more than that creates a large inventory, not a backlog. If there are a considerable number of features, apply some prioritization method to select the top ten features.
Map the steps of a Feature
Feature Steps Mapping is a technique that helps break a feature into small work itens. Each step will be a PBI – Product Backlog Item.
PBIs are elements that make up the Product Backlog. Ideally, PBIs reflect customer and business needs, which can vary in specifications and requirements. Typically, these are represented by use cases, epics, user stories, or even bugs or tasks.
Breaking a feature is done through mapping its steps, which represent a mapping of a feature’s work items.
Start by asking the very first work step to get started on the feature. Write it down. Then ask about the second work step. Then the third and so forth, until completing the feature workflow, step by step. Note that each work item represents a step towards feature construction.
For example, consider the sample feature: Make Online Purchase. What is the feature first step? To conduct a product query; What after? To make product selection; then to make product payment and so on. These are the Steps Map.
Identify the Backlog Items
At the time of backlog construction, the suggestion is to represent each PBI by the ARO model – the representation begins with a verb, followed by the desired result, and ends with the object within context. Then, you can to convert each PBI into a User Story, the most common representation to describe what should be done to meet end user needs.
ARO Action-Result-Object
From the original article:
“[action] the [result] [by|for|of|to] a(n) [object]
As examples, consider these:
- Estimate the closing price of stock
- Generate a unique identifier for a transaction
- Change the text displayed on a kiosk
- Merge the data for duplicate transactions”
Read more about the ARO model here.
PBIs: For each feature, write their respective PBI’s. First, write in the ARO model, and then represent each PBI as a User Story. Arrange the items vertically, where the highest one has the highest priority.
Scrum does not specify how to represent each item in the Backlog, so you can write it in various ways. User Story is the most used form by agile teams today to represent an item in the Backlog. A User Story is a brief description of what is required for a customer to have in the product, which basically answers 3 questions: WHO? WHAT? WHY?
PBB help in writing the User Stories. As you can see in the PBB Canvas, we have the “WHO?” Which is the persona, the “WHAT?” Which in this case are the PBIs already represented in ARO model and lastly the “WHY?” Which is in the objectives and benefits that the persona highlighted in the feature block. The figure below gives a simple illustration of how easy it is to write User Story with the help of the Product Backlog Building.
The greatest benefit of Product Backlog Building is the facilitation and collaboration that it brings in everyone involved in building a Backlog. So, let´s build an awesome backlog with very well though and structured backlog items!
>> Check out the PBB Canvas Tip Sheet
>> Running a remote PBB session? Check out the PBB canvas template for Mural
