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 & Sprint Backlog level planning is critical for successful Product Backlog Prioritization. Below mentioned questions will help you in accessing the preparedness.
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 |
There are two metaphors that are commonly used to illustrate the dynamics of the backlog. They are:
A well-balanced backlog is:
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
A well-maintained product backlog is crucial for successful product development. It serves as a single…
Incremental value to the customer refers to the gradual delivery of small, functional parts of…
A Product Market refers to the group of potential customers who might be interested in…
The Professional Agile Leadership - Evidence-Based Management (PAL-EBM) certification offered by Scrum.org is designed for…
The Professional Agile Leadership (PAL I) certification, offered by Scrum.org, is designed to equip leaders…
Choosing the right Scrum Master Certification depends on your current experience and career goals. If…