Product Backlog Refinement
After reading through this write up you will be able to understand
- The importance of Product Backlog refinement for development team working in sprints.
- Role of different stakeholders and their participation in making the backlog refinement more meaningful.
- Few important logistics for conducting effective backlog refinement session.
- Typical activities that take place during the backlog refinement.
Product Backlog Refinement
Product Backlog refinement, also popularly known as Backlog grooming, is an informal Scrum team ceremony that happens every sprint, in which everyone in the team, including Scrum Master and Product Owner get together to ensure that work items in the backlog are relevant and useful, and each items aligns to the overall product roadmap. It is indeed more of a working session than a typical closed door meeting.
Why backlog refinement?
- It largely discovers the unknowns and uncertainties that are going to share up in future during the product development. It also helps in understanding the bigger risks of the future product development.
- Regular and continuous Backlog refinement prevents “Scope Creep”, which means working on delivering something more that may not be valuable to the customer or something which results in significant budget overruns. In the absence of backlog refinement, the backlog may become partially or fully outdated, that may not suit the changing business needs.
- If you see there are lots of gaps in requirements, you probably may have to assign an action item on your PO, to come back.
- For any big technology issues or architectural issues or bigger unknowns, the team needs to work with a System architect to figure out the next steps.
- Always make sure that someone who is assigned with an action item reports back before the next planning meeting.
- If a change in the acceptance criteria of a work item has been changed, then the team should probably look at re-estimating it.
- The Scrum master should ensure that risk identification should not be dominated by single person let everyone speak up.
- Since, every team member are supposed to present in this meeting, in a way, it increases the team collaboration through knowledge sharing and learning. It also helps team to maintain sustainable pace.
- It also decreases the time for the next sprint planning meeting. A backlog refinement meeting is also called the sprint pre-planning meeting. PO will always have a good indication on which work to prioritize for the next sprint planning meeting based on the size and complexity of the work item.
Logistics of Backlog refinement:
- Teams typically have a standard cadence for grooming the backlog. They often have one meeting per sprint. In a 2 week sprint, it commonly alternates with Sprint Planning meeting.
- Do not schedule backlog refinement either in the early first part or the late last part of the sprint. Usually during the early first part of the sprint, the team members will try to settle down and start the work and there is every chance that the team could get distracted. If you schedule it during the late last part of the sprint, the team members will be in hurry to wrap their sprint goal and there is chance it could jeopardize the same.
- The recommended practice is could be the same day, every other week. It is the only time work not in the sprint is discussed. Usually it is a good idea to allocate 5%-10% of the sprint time for this event.
- It is recommended that atleast 2 sprints of work items are available readily groomed in the backlog, so that the team might want to pull them, whenever needed.
- This ceremony typically follows the concept of “Progressive Elaboration” which means that as we progress more into our product development, more details on the scope of work will be uncovered.
- Remember that it’s not required that all product backlog items need not be perfectly understood at the beginning of a sprint.
- The features only need to be sufficiently understood by the development team so that they have a reasonably strong chance of completing it during the sprint.
- A team can have more than one backlog refinement every sprint; it all depends on state of the backlog.
- Please rise backlog grooming issues (if any) in the next retrospective and make sure that the team suggests necessary improvements, by following inspect and adapt.
- Make it fun, entertaining and engaging, so that everyone loves attending the backlog refinement session.
- In order to derive maximum value from the backlog refinement meeting, it is recommended that backlog grooming meetings are Time boxed, with strict agenda, a specific goal in place and PO come prepared.
- It may be Okay for managers and other stakeholders to attend this session, but Scrum Master has to work towards limiting their participation only to listening and jump in when they are asked relevant questions on the backlog items being discussed.
- Mike Cohn, the founder of Mountain Goat Software, proposed acronym DEEP to summarize key attributes of a good product backlog
|Highest priority, more detail; lower priority, less. Broken down into smaller stories for sprints/release
|Growing and evolving overtime; Re-prioritized when items are added/deleted
|The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points.
|Items that are slated for the next couple of sprints
Product Owner involvement:
- The product owner involvement is vital in backlog refinement.
- It is always recommended that PO should spend atleast 30% of his available time with the development team during a sprint.
- The PO makes important decisions about acceptance criteria, acceptance tests, logic details, and priority of the work items during the backlog grooming meeting.
- Ideally a grooming meeting has most verbal conversations that engage PO and development team. The Scrum Master facilitates this ceremony
Typical activities during the backlog refinement are
- Reviewing the highest priority stories on the top of the backlog
- Ask questions to product owner for more information.
- Deleting stories that are no longer needed
- Writing new user stories
- Re-prioritizing and force ranking the stories
- Re-define the acceptance criteria
- Creating new user stories when necessary
- Estimating or re-estimating stories
- Re-assessing the relative priority of stories
- Breaking the epics further into user stories
- Refining stories to prep for future sprints
- Understand the changing bigger picture of the product architecture as the backlog emerges.
Scrum Smells if
- There are no backlog refinement sessions
- The entire team not present, only leads try to understand more than others
- The stories need to be groomed / estimated during sprint planning meetings
- There is lack of sufficient acceptance criteria for user stories.
- The time spent grooming stories is not proportional to its position in the backlog