Product Backlog Refinement consists of Creating & Refining User Stories, Estimating User Stories & Product Backlog Prioritization. It is the act of adding detail, estimates, and orders to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Scrum Team collaborate on the details of the Product Backlog, refine and revise it. It ensures that the Team and Product Owner have sufficiently defined Product Backlog items so that Sprint Planning runs more smoothly and without surprises. It is an exercise performed out of which a prioritized list of work emerged. Product Backlog is the single source of requirements for any changes to be made to the product.
Product Backlog Prioritization
Product Backlog & Sprint Backlog level planning is critical for successful Product Backlog Prioritization. Below mentioned questions will help you in accessing the preparedness.
- Is the team sure the user story on top of the backlog is the one with the best outcome and the highest value?
- Are the Stories and story points captured and estimated?
- How can we measure quantitatively the success of the user story? What metrics can be applied?
- Release plans are forecast at the velocity level for sets of or themes of Product Backlog Items or user stories? Is the user story in line with the overall product vision?
- Are user stories broken down into tasks? Is the sprint goal clear to the scrum team? Is there an actionable plan to achieve the sprint goal?
Questions to access Definition of Ready for the user stories and guidance on action items.
| Qualities | Criterion assessment’s questionnaire | Actions to be taken if one or more answers is/are negative(s) |
| Independent | Q: Does the completion of the user story depend on another user story? Q: Does all the needed information regarding the user story available? Q: Can the user story be completed without the help of anyone else outside the team? | A: Identify and prioritize the user story needed as a prerequisite. A: Postpone the user story to a later refinement session Invite the right audience during the refinement (functional and technical). A: Have a complete cross-functional team before starting the implementation. |
| Negotiable | Q: Is the team free to choose the best and less costly way to implement the user story? | A: Rephrase the user story to give more leeway to the team Stick with the “what”, don’t prescribe the “how”. |
| Valuable | Q: Does the user story’s value easy to grasp? Q: Does the team understand this value? Q: If I put myself into the customer’s shoes, will I be thrilled to see this story done? | A: Rephrase the value to make it tangible. A: Re-explain it to the team until they get it. A: If no real value can be found, drop the story. |
| Estimable | Q: Can the story be estimated by the team? | A: Break down the story into pieces, then go through the refinement activities. |
| Small | Q: Are the estimates not too large? Q: Is the product owner able to clearly answer all the team’s questions? | A: Break down the story into pieces, then redo the refinement activities. A: Work out the unanswered issues by inviting the right audience. |
| Testable | Q: Does the team know when the story is done? | A: Craft tangible acceptance criteria in form of test cases, to be written down before the implementation |
Common Metaphors
There are two metaphors that are commonly used to illustrate the dynamics of the backlog. They are:
- An Iceberg: 90% of the stories should be course-grained, and “below the surface”; so, we’re not paying attention to them.
- A Pyramid: Again, the foundation is large and full of epics. The top or tip is what’s interested. It does align with stones, which are a common metaphor for story granularity.
20-30-50 Rule
A well-balanced backlog is:
- 20% proper stories ready to roll; execution ready in the next sprint or two.
- 30% are larger (8-13-20 point) stories or epic stories that will eventually be split out into smaller finely grained ones; targeted for the next release point.
- 50% are large epics or themes—vague ideas about long term product direction. I never put much effort here because it’s almost always wrong.
Product Backlog Prioritization Tools
While Prioritizing Product Backlog you must consider other factors, like –
Business value: For user stories that represent features, then this is relatively clear. For tasks, research spikes, re-factoring work, training, bug fixes, etc. the distinction isn’t quite so clear, but it’s equally important. Therefore, the business value needs to be carefully weighed against a wide range of work.
Time value: If you view the backlog as a representation of a project schedule, then the timing of delivery truly matters. For example, if you need to perform some work on testing infrastructure, then doing it too late in the release sequence simply devalues its impact on the project; just as deferring any critical bug fixes until the final sprint is a poor strategy.
Dependency value: While we desire independence (the “I” in INVEST) as a prerequisite for good user stories, the harsh reality is that there will be strong dependencies that come into play for meaningful execution. These will need to be accommodated as you plan for delivery. A good example of this is a set or theme of stories that implement a specific customer workflow for a release. They will all need to be delivered together to realize the value. Another good example is to have multiple teams working on sets of stories that have cross-team dependencies, at the same time. Then the stories would need to be integrated to realize their full value or potential.
Technical value: If you’re collaborating effectively with your team, you realize that their opinions on technical flow are important. So, when you implement features from a development perspective considering architecture or infrastructural dependencies, ease of implementation, the natural flow of implementation, ease of testing, and team member availability; all of which fundamentally matters from an efficiency and cohesion perspective. It also helps team morale if you listen to, and consider, their expertise and overall availability.
Prioritized Product Backlog indicators
| # | Description |
| 1 | Sprint planning is short, easy, and should take 2 hours or less for a 2-week sprint. There are NO architectural or design or sideway discussions within the meeting. |
| 2 | The team members are enabled for taking a decision on epics and stories targeted for at least three future sprints. So, everyone understands and align with the Product Owners’ vision. |
| 3 | The team finds it easier to contribute new technical and NFR stories to the Product and Sprint backlog e.g. testing artifacts, non-functional requirements, refactoring, automation development, performance tuning, research spikes, etc. |
| 4 | The team has a feel for where the product is going long term and maps efforts, designs, theme suggestions, and trade-offs towards that vision. |
| 5 | The sprint goal is easily derived from the backlog. |
| 6 | The Product Owner includes team feedback received during Sprint Retrospective in EVERY sprint. |
| 7 | The Product Owner rarely changes the priority of elements purely because of size estimates. Team’s estimate is more aligned with actual effort. |
| 8 | Sprint planning is done every 2-3 weeks, not only as a planning tool but also as a risk or adjustment tool. The point is end-to-end planning towards the next release milestone occurs iteratively and frequently. |
| 9 | Teams are hitting stretch items and pulling in more work per sprint. There is an enthusiasm to deliver more towards goals by creatively trading off story sub-elements with heavily collaborated with the Product Owner. |
| 10 | The backlog is mapped to the teams’ skills and capabilities, stretching them – yes, but not asking them to do things they are not capable of doing either by skill or experience. |
| 11 | Within every sprint, the Product Owner is making micro-adjustments to scope based on interactions with the team. Always striving for that Minimal Marketable Feature and Product set! |
| 12 | The team is never surprised in sprint planning. |
| 13 | The team feels they have a say in what’s on the backlog and the distribution of features vs. improvement items. |
Scrum Guide – Click Here