Imagine gathering requirements as like fishing. You don’t want to catch every single fish in one haul as the processing of that would mean that some fish would go off. Focus on catching the big fish first by using a wide net, then later you can use a finer net to catch the smaller fish. This is the same with requirements as with the big requirements you can use them to understand the product direction better.
Definition: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
Length: “Refinement usually consumes no more than 10% of the capacity of the Development Team” (1)
People: Product Owner, Development Team
Outcome: Product Backlog items become more transparent through refinement and the top items are deemed ‘Ready’ for a Sprint (i.e. can be ‘Done’ by the team within one Sprint)
Benefits
Product Backlog Refinement Benefits (2, page 103, Mastering Professional Scrum)
Increased Transparency – adding details for what you plan to deliver, and your progress
Clarification of Value – outcomes of what you are trying to achieve become clearer, and helps the team to build the right thing
Breaking things into consumable pieces – increases flexibility for the team to meet ‘Done’ in a Sprint
Reduction of dependencies
Forecasting
Incorporation of learning – gained learning is incorporated into the product
Facilitation Techniques
Fishbowl collaboration (3)
Three – five people collaborate around a whiteboard (the fish in the bowl)
Others in the room may observe but are not allowed to speak
If someone from outside the bowl wishes to speak they can dive into the bowl which bounces out one of the fish already in the bowl
People can leave anytime if they are not finding it valuable
This technique keeps the conversation small and productive
Three Amigos and BDD
Backlog Refinement is attended by someone to represent each discipline in rotation (i.e. Three Amigos of Product, Development, Testing)
Behaviour Driven Development is used to focus the conversation on the behaviour of the User Story
Use the question of ‘Which features in our product backlog are needed in order to have a successful product release?’
Test the list generated against the question ‘If we delivered all of out must-do PBIs except this one, would we still have a successful product release?’
‘Same-size’ items (all PBIs are roughly the same size)
‘Right size’ items (at least one item can be delivered in a Sprint)
Probabilistic Estimating (page 110, Mastering Professional Scrum)
Monte Carlo is an example of probabilistic estimating
Uses historical data with a statistical sampling method
Output is a range of possible future outcomes with a confidence level on that range
Embraces uncertainty of predicting the future
Estimation Caution
Asymmetric nature of software estimation errors (2, pg 203)
‘ There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say. We know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know’
Former Secretary of Defence Donal Rumsfield
Estimations are more likely to take longer than expected than they are to take a shorter amount of time than expected (i.e. they are asymmetric)
Developers estimate based on known knowns, and sometimes known unknowns.
Some error comes from misunderstanding these
Most comes from unknown unknowns
Larger tasks are more likely to have more unknown unknowns so the risk of rapidly increasing is much higher
Cone of uncertainty shows that the likeliness of under as over-estimation is symmetric
This technique is used for evaluating potential product opportunities
Importance vs Satisfaction (2, pg 47)
Competitive example is Excel. High important to users and it is the leading example. So product in this space to compete needs to be something like the online sheet tools for collaboration
Opportunity example is Uber where user satisfaction was low with taxi service but their need for a solution is very important to them
Measuring Customer Value
When importance and satisfaction are both percentages:
Customer value delivered = importance x satisfaction
Opportunity to add value = importance x (1-satisfaction)
Customer Value Example
For orange it is:
Customer value delivered: 0.9 x (0.35-0.2) = 0.135
For blue it is:
Customer value delivered: 0.6 x (0.9-0.6) = 0.18
So blue created marginally more value than orange.
The Kano Model (2, pg 64)
Performance needs – adding more will increase satisfaction. For example fuel efficiency on a car. Increasing this will always increase satisfaction.
Must-Have needs – they never increase satisfaction. They only decrease it if they are missing
Delighter needs – the customer is not dissatisfied at all if they are missing as they are unexpected and result in very high satisfaction if they are included
Existing product problem statement elements (1, pg 25)
The current goals of the product or system
The problem the business wants addressed (i.e. where the goals aren’t being met)
An explicit request for improvement that doesn’t dictate a specific solution
[Our service/ product] is intended to achieve [these goals].
We have observed that the product/ service isn't meeting [these goals] which is causing [this adverse effect] to our business.
How might we improve [service/ product] so that our customer are more successful based on [these measurable criteria]?
Template (1, pg 26)
New product problem statement elements (1, pg 27)
The current state of the market
The opportunity the business wants to exploit (i.e. where the current solutions are failing)
A strategic vision for a product or service to address the market gap
The current state of the [domain] has focused primarily on [customer segments, pain points, etc]
Our product/ service will address this gap by [vision/ strategy]
Our initial focus will be [this segment]Template (1, pg 27)
Stories express something that will be valuable to a user (2)
Benefits of User Stories
They act as a placeholder to remind us to have conversations rather than follow written requirements contracts
They encourage interaction through the conversations
They are comprehensible by all, from devs and throughout the business, and have no technical jargon
They are the right size to be able to plan and estimate
When working iteratively we don’t have to write all stories upfront and can refine as we go along the project
Splitting Stories
Vertical Slicing
Always slice stories from the point of view of our customer
All stories must have value, which can be to our customer directly or indirectly
The technical layers that make up the value are to be kept together (like the layers of a birthday cake) as one layer on its own does not provide value
Splitting stories into the technical layers can lead to defining the solution and restricting abilities to creatively iterate
Use these scenarios to break the story down into smaller pieces of value
Cake Metaphor (3)
Cake Metaphor Doodle
To split the story down you could break it down horizontally and take each ingredient in turn
But if you slice horizontally you will just get egg and not know if the cake ingredients all work together to provide value (it could taste awful all together!)
Instead, bake a cupcake!
You get all the ingredients but a smaller size to check the recipe works
A Cupcake Doodle!
User Story Construction
The Three C’s
CARD
Description that defers the details
As a [user type]
I want [functionality]
So that [benefit]
CONVERSATION
Verbal conversations are best
Highlights that we don’t know all the detail
Reminder of conversations we have had, work that has been done, any wider context
Confirmation
Acceptance Criteria
Must be matched for a story to be considered done
User point of view only
No design specifications unless the user wants them
Good User Story Guidance
INVEST Criteria
INDEPENDENT
Stories shouldn’t have to be completed in a specific order and should not rely on another story to be started
This is not always achievable
Common examples are when you need something to exist before you can build upon it or when one story reduces the complexity of another making it seem logical to do them in a specific order
How do we respond to this?
Don’t put dependent stories in the same sprint to keep the flow
Join together dependent stories
NEGOTIABLE
Stories are not contracts – they are short descriptions of functionality
Open to discussion with the team
Simplify, alter, add to in whatever way is best for the goal and the product
VALUABLE
Valued to user/ customer
Technology assumptions have no value to the customer!
ESTIMABLE
Good size
Just enough information, but not too much to become confusing
If an investigation is needed before estimation, use a spike
SMALL
Lower Limit is coffee break size, i.e. big enough that you deserve a coffee break for finishing
Scrum team will highlight size issues in refinement
TESTABLE
Language is important
It must be specific, unlike “A user never has to wait for it to load”
“It takes two seconds max to load in 95% of cases” is much better
Acceptance Test Writing Guidance (2)
Always add tests as long as they add value
Capture assumptions
Provide basic criteria for when story is Done
Questions to ask
What else do devs want to know?
What am I assuming?
What can go wrong?
Circumstances where story might behave differently
Usability
Stress
Performance
Stories should be closed, not open ended
Use language to ensure that the stories have a definite closure
Continuous jobs are bad (e.g. managing an ad)
Instead use closed actions like “review responses” and “edit response”
User Story Card Example(3)
User Story Card Doodle
Story reference number
Author of the story
Value/ importance
Status/ release
Size/ estimate
Date created
Dependencies
Metrics (if relevant)
Description
Story title (this is the only mandatory field)
User Story Smells
Too Small
EVIDENCE: Frequent need to revise estimates depending on order
FIX: Combine the stories together
Not Independent
EVIDENCE: Difficulty in planning the iteration and lots of swapping stories in and out
FIX: Re-split the stories
Gold Plating
EVIDENCE: Extra wow factor being added that isn’t in the story
FIX: Increase the visibility in the Daily Scrum
Too Much Detail
EVIDENCE: Too long discussing the story
FIX: Strip the story back to its basics and focus on the user point of view
Trouble Prioritising
EVIDENCE: Stories cannot be prioritised logically
FIX: Stories may need to be broken down smaller or re-written from a value point of view
