Team A has identified a few features and now wants to build the backlog of User Stories for the upcoming few Sprints. How to do it?
Step 1 – Features and Milestones
First, make sure everyone understands how the features belong together. For example, below is a sample features sequencer. On it, everyone can see that the MVP consists of F1, f2, F3 and F4; the product increment consists of F5, F6, F7, F8 and F9.
This artefact is generated by a Lean Inception workshop. If you do not have a Features sequencer, you need something that shows features and milestones. On the Lean Inception, the features are planned via MVP and product increment milestones.
Step 2 – Feature Steps Mapping
You have to breakdown each Feature in small steps, the User Stories.
The image below depicts the feature F1, which was broken down into four user stories: 1.1, 1.2, 1.3 and 1.4.
Before breaking down the Features, you must validate everyone is aligned about the feature. The following activities ensure such alignment.
2.1 Rewrite the Features (optional)
Rewrite each Feature so it is written as 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?
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 prioritisation method to select the top ten features.
Feature Rewrite Example: Sell products online -> Make online purchase
2.2 Identify the personas
Every Feature should fulfil a need or remove a pain for a persona. So, identify the persona. Write the persona on a post-it of different color and place above the Feature.
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. These questions test if your Features full-fill the need of a persona.
Persona Example: Online Customer
2.3 Describe the benefit
Describe the “Problems” and the “Benefits” related to each Feature. Write down the feature’s problems and the feature’s benefits on another post-it color and position on the left and right side of the post-it with the feature description.
Benefit Example: Save $
2.4 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 search for a product; What after? To make product selection; then to compare options and so on. These are the Steps Map.
Steps Map example: Make online purchase (FEATURE)
- STEP: To search for a product
- STEP: To make product selection
- STEP: To compare options
- STEP: To add item to shopping cart
- STEP: To fill up payment info
- STEP: To fill up delivery info
- STEP: To review detailed purchase
- STEP: to confirm purchase
2.5 Identify the Backlog Items (PBIs)
At the time of backlog construction, the suggestion is to represent each PBI by the ARO (Action-Result-Object) 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 the persona needs.
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.
ARO example: Compare similar options of an item
2.6 Represent the PBIs as User Stories
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?
On the previous activity, for each feature, you wrote their respective PBI’s in the ARO model.
Now you should represent each PBI as a User Story. The following image shows how you can do it by reutilising the notes from the previous activities.
Features Steps Mapping is part of PBB, a canvas and a methodology writing the User Stories. From your previous activities, you have the “WHO?” (the persona), the “WHAT?” (the PBIs already represented in ARO model) and lastly the “WHY?” (the problems or benefits for the feature). The figure above gives a simple illustration of how easy it is to write User Story with the help of the Product Backlog Building.
As a WHO (persona)
I want to WHAT (feature step)
So that WHY (benefit) – Tweet This.
User Story example: As an Online Customer, I want to Compare similar options of an item, So that I save $.
Step 3 – Milestones Mapping
You don’t need to finish all user stories from Feature 1 to start on the User Stories from Feature 2. Typically, there are correlations and reasons for a group of user stories to be worked on at the same timeframe. These form the milestones. A few examples: “Payment Flow 1 UI complete”, “Ready for stress test”, “Security level 1 achieved – ready for testing internally”
These milestones should mainly consider the user stories and the logical order in which they should be worked on and released.
Step 4 –Sprint planning
Here is a step-by-step for to plan the User Stories (connecting them to their respective Features and milestones) into the next few Sprints.
1. Create the Team Features Milestone per Sprints table:
– the time goes horizontally; columns Sprint 1, Sprint 2…
– the Row 1 indicates the milestones/ events (e.g. “Milestone X”, Feature Y completed”, “MVP ready”
– the Row 2 is the team name (e.g team A)
2. Distribute the User Stories as per the Team-Sprint combination. Please respect the team capacity for a Sprint.
3. Add arrows and colours to represent dependencies between user stories
4. Describe the important milestones and events.
