Product Backlog Refinement

Product Backlog Refinement or Grooming is an exercise out of which a prioritized list of work emerged. It consists of Creating & Refining User Stories, Estimating User Stories & Product Backlog Prioritization. Product Backlog is the single source of requirements for any changes to be made to the product. This is for the development team that is derived from the roadmap and its requirements. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The development team doesn’t work through the backlog at the product owner’s pace and the product owner isn’t pushing work to the development team. Instead, the development team pulls work from the product backlog as there is the capacity for it, either continually (Kanban) or by iteration (Scrum).

Product Backlog Refinement Approach

  • Top-down (Prepare the context of the product) – Start with the Product Goal, Product Vision, and supporting documentation like the Business Case to populate the Product Backlog. Focusing on what will resolve current business issues in the next Sprint is the key. Create the product roadmap, show how the features and the user stories fit into the product roadmap
  • Story Mapping – Examine the context and the steps required for a user to complete an activity. Break each activity into Stories. Order the user stories and features based on the highest business value always on top.
  • Investigations & experiments – After a formal, collaborative Backlog Refinement session, the Team members identify key areas in which to do some analysis, investigation, and R&D. The goal of the activity should be clear and timeboxed with the outcome explicitly reported to the Team and recorded against the Product Backlog item. No actual work should be undertaken to progress a Story.
  • Design Spikes (options analysis) – After a formal, collaborative Backlog Refinement session, the Team identifies which future Stories have significant unknowns and several potential ways of implementing them. These are targeted for a timeboxed options analysis with the results brought back and discussed with the Team at the next Backlog Refinement or future Sprint Planning session.
  • Cynefin – Using the Cynefin sense framework, the Team assesses whether Stories are ‘simple’, ‘complicated’, or ‘complex’. Patterns for Complicated Stories are identified. Design Spikes are identified for complex Stories. The best practice is agreed upon by the Team for simple Stories.
  • To size or re-size – If the Team has already sized a PBI, ask whether the Team has learned anything new by asking for a Roman Vote. If the Team has learned nothing new, then move on to the next PBI.

Product Roadmap

A product roadmap is a high-level visual summary that maps the vision & describes how a product is likely to grow, align the stakeholders, and acquire a budget for developing the product. It’s a guiding strategic document as well as a plan for executing the strategy. It provides strategic direction & ties back to the strategy for the company. The goals of a product roadmap are

  • Describe the vision and strategy.
  • Provide a guiding document for executing the strategy.
  • Get internal stakeholders in alignment.
  • Facilitate discussion of options and scenario planning.
  • Help communicate with external stakeholders, including customers.

Product Backlog Refinement

Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint. An easy way to make Sprint Planning meetings both shorter and more effective is through the regular use of Product Backlog Grooming Sessions.

A Backlog Grooming session can be used to:

  • Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more Story Time sessions).
  • Break down user stories that are too big (epics to user stories),
  • Improve user stories that are poorly written.
  • Estimate backlog items.
  • Add acceptance criteria.
  • Look deeper into the backlog to do longer-range technical planning.

During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask questions that would normally arise during sprint planning. By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.

WHO

Product Backlog Refinement is a collaborative effort involving:

  • (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
  • (Optional) representative(s) from the Management Team – clarify the high-level priorities
  • (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
  • (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed-upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

WHEN

The best time to perform backlog refinement is during the previous 1 or 2 sprints where the team can sit down to discuss the upcoming work. Depending on the velocity of your team you should meet biweekly or weekly. A preferred combination is three days before the end of the current sprint & weekly meeting so that the product owner has sufficient time to act on any issues that are identified.

Few questions to Product Owners regarding Backlog Refinement:

  1. What’s the idea behind product backlog refinement?
  2. How would you organize the process of refining the product backlog?
  3. How many user stories can you work on in parallel while ensuring their continued relevance to customers and the organization?
  4. At what stage do you include other team members in the refinement process?
  5. How do you handle bugs and technical debt when there are a lot of valuable new features competing for resources?
  6. What should a good user story look like? What is its structure?
  7. What are the most common pitfalls of product backlog refinement?
  8. When would you remove a product feature?

Pre-requisite

  • Top-order the product backlog to reflect the greatest needs of the Management Team and the Product Owner Team
  • Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research
  • Periodically review epics, features or other items on the Management Team roadmap

Planning at Product Backlog & Sprint Backlog Level

  • 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?

Guidelines for effective Product Backlog Refinement

  • Link Product Backlog with Product Roadmap: Map Product Backlog to Roadmap. Product Roadmap is used to sketch the overall journey you want to take your product on. State the upcoming major releases with their goals or benefits. Then, derive your product backlog from the roadmap and use the goals to discover the right backlog items. This ensures that your backlog is aligned with the product strategy and it helps you decide which items should be added to the product backlog and which should not.
  • Order the Product Backlog for Clarity: The product owner backlog should be ordered by value, with the value being relative to the product that you’re building.
  • Focus on the next major release use stories: Use product backlog as a tactical tool that states the product details – including epics and user stories – that have to be implemented to deliver the next major release.
  • Have a goal in mind: The product owner should have a clear goal in mind before coming to a backlog grooming session. This can be an agreed-upon goal with the team, but the point is the goal should be set before the meeting starts.
  • Focus on Emergent Requirements: Uncover the details of high-level features progressively rather than upfront before development starts. So we should solicit a high-level list of requirements from the customer, prioritize them, and refine top priority items as we progress.
  • Understand Dependencies to remove Impediments: There are dependencies on product backlog items in the form of technical constraints, business decisions or other external/internal teams. Product Owner should be cognizant of dependencies to ensure best Sprint Planning sessions and help teams avoid impediments during a Sprint.
  • Focus on relative estimate via user stories: You shouldn’t spend a lot of time on it. Instead, techniques like poker planning or affinity estimation allow Development Teams to quickly forecast a product backlog. This will help you to negotiate scope with the masses and will appease stakeholders with a date.
  • Implement Layers of Decomposition: Your layers of decomposition should include objective, feature, and user stories. For example:
    • Capability –
      • Feature (Epic) –
        • User Story –
        • User Story -Feature (Epic) –
          • User Story –
          • User Story –
          • User Story –
  • Say No: Decline ideas and requirements that do not help you meet the release goal and move you closer to realizing the product vision. This ensures that your product has a clear value proposition and it prevents your product from getting bloated. If the idea or requirement is important but cannot be realized in the next few months, then consider adding it to the product roadmap.
  • Limit “chicken” participation: known as “chickens” in Scrum, stakeholders can be effective participants in a backlog grooming session. But limit their numbers.  If you have, for example, 10 stakeholders from whom you want to gather feedback, get it from them in a series of 2 – 3 meetings, not one big one.  Remember, stakeholders often do not understand the rules of Scrum as well as the team, Product Owner and ScrumMaster do.
  • Get Feedback and Reflect: The Product Owner must be open to seeking feedback & take action for continuous growth. Product owner should
    • Engage development with cadenced, time-boxed backlog refinement sessions.
    • Schedule time with the appropriate stakeholders and seek them out if they had input at the Sprint Review.
    • Be creative in how you get into the mind of your customers.
  • Visible and Easily Accessible Product Backlog: The Product Backlog should be clearly visible and accessible so that it will be transparent and can be used as an alert when your backlog is becoming too big.

Backlog refinement process objective

Your goal is to make sure your product backlog is always DEEP:

  • D – Detailed– Detailed appropriately so that items at the top of the list have more detail than those at the bottom.
  • E- Estimated – Each product backlog item, or at least those involved in the next release, should be estimated by story points or time. As your team gets more work under its belt, its velocity – the rate at which it finishes items from the product backlog – will become clearer and make estimating easier.
  • E- Emergent – This means the product backlog is adapted to new items or information that emerge.
  • P- Prioritized – All items on the product backlog are ordered with the most important ones at the top.

User story characteristics

  • I – Independent – Stories should not overlap and ideally can be implemented in any order.
  • N – Negotiable – The story captures the essence but not the details, which are agreed upon by the participants.
  • V – Valuable – The story offers clear value to the customer.
  • E – Estimable – You are able to assess the effort involved. This might be a time estimate or in what are called story points, an arbitrary unit of measurement that rates relative complexity (such as XS, S, M, L, XL, or 1, 2, 3, 5, 8).
  • S – Small – “Good stories tend to be small,” Wake said. This means that the story should be accomplished in (at most) a few 40-hour work weeks by a dedicated person, or divided among team members.
  • T – Testable – The user story should be measurable or actionable in some way.

Scrum Guide – Click Here

Recommended Practice Exams

Scroll to Top