Product Backlog Refinement

Refinement is the act of preparing possible Product Backlog Items for future Sprints. The Product Owner refines the Product Backlog by adding detail, collecting estimates of the work, and clarifying the context of upcoming PBIs through conversation with stakeholders, Developers, and partners from other departments like security, operations, legal, compliance, marketing, etc. depending on the type of work done. Product Backlog Refinement is not a single event. It is considered an activity because it is ongoing (the Product Owner works on refinement of the Product Backlog continuously).

The Refinement Meeting is a meeting between the Product Owner and the rest of the Scrum Team to discuss upcoming work in the Product Backlog, create alignment, further refine where necessary, and estimate the work. Every Scrum Team decides how and how often to do it. Typically, the team meets at least once per Sprint, but some teams choose to meet more often for continuous refinement of the Product Backlog and more frequent alignment between Product Owner and the Developers.

The role of the Product Owner

For the Product Owner, Product Backlog Refinement is a continuous activity. As they learn more about customer and business needs, changes in priorities, and details of the work, the Product Owner updates description, details, and order of PBIs. The Product Owner gets ideas and inputs about potential PBIs from multiple sources as described in the picture.

The PO refines the Product Backlog Items in the Backlog to prepare them for a possible, future Sprint. There is no commitment at this stage, as things may change in the future. For now, all the PBIs refined are potential candidates for future Sprints, but things may change before we get there. Some PBIs may be removed from the Product Backlog (the Product Owner says “No” to them) as they may no longer be valuable. Other may be added, as the Product Owner discovers new needs or new priorities.

The decision on whether the team will actually work on these PBIs, or not, will be taken later in time, at Sprint Planning.

The Product Owner and the Developers meet regularly to collaborate on Product Backlog Refinement in what is called a “Refinement Meeting” (some teams call this “Grooming” but the term is frowned upon and we prefer the more appropriate “Refinement”).

Here, the Product Owner shares details about the PBIs that potentially could be worked on by the team in future Sprints. The PO and the Developers collaborate in clarifying the expectations of each PBI, by refining the Acceptance Criteria, and by creating a shared understanding about the work. In addition, the Developers support the Product Owner by providing estimates of the effort required for each PBI. These estimates may help the Product Owner determine possible forecasts for release planning or for setting stakeholders’ expectations.

Tips

At the start of the meeting, the Product Owner reminds everyone about the Product Goal.

The Product Owner provides context about the PBIs so that everyone understand what is expected, before estimation.

The team should refine enough PBIs for the next 2-3 Sprints. Anything beyond that may remain undefined because things may change.

There is no fixed time for refinement, instead agree with the team how often to meet for it (e.g. 1 times per week, 3 times per week, once per Sprint, etc.)

Neither the PO nor the Scrum Master are secretaries: the Developers collaborate during refinement and they can add additional details to the PBIs to clarify ideas or specify expectations (e.g. Acceptance Criteria).

Extend the invitation to the Refinement Meeting to other people who may help with the refinement of PBIs or with the removal of dependencies: for example, invite a couple of team members from another team on which your team depends. Or, invite SMEs who may help clarify some of the work.

Do Not

Refinement is not intended to be definitive. There is no commitment at this stage, as things may change in the future. Commitments happens at Sprint Planning.

Do not pre-load the next 2-3 Sprints. Refinement is not pre-planning. Things may change before the next Sprint, and we should be open to that change.

Do not get into the “how” or the implementation details. Only discuss technical details that may affect the estimate. Any discussion on technical implementations may be deferred to the “how” part of Sprint Planning.

Do not do refinement all at the beginning of a new project. This is upfront planning and is not suitable for an empirical Scrum environment.

Do not ask one person to take notes: everyone on the team should contribute to the refinement of the details of each PBI.

The Scrum Master acts as a facilitator, ensuring everyone participates effectively and that the meeting is productive.

The Scrum Master should keep the hands off the keyboard: do not act as a scribe, instead make sure everyone contributes to jot down details and ideas for each PBI discussed.

The Scrum Master should coach everyone on how to have an effective Refinement Meeting. For example, invite the Product Owner to begin the meeting by sharing the Product Goal, so everyone is aligned on the overall objective.

The Scrum Master should also ensure that the conversation focuses on creating a shared understanding about future work that the team may be asked to do. This means dedicating time to discussing expectations for each PBI, and not just doing estimation.

Scrum Master should timebox the discussion on each individual PBI to avoid going down a rabbit hole: set a timer of 5 minutes for each PBI, and if more time is needed, confirm with the Developers that more time will help to clarify the understanding of that PBI (instead of negotiating tech details for implementation).

Refinement is considered an activity, rather than a Scrum meeting. For the Product Owner, refinement is done every day as part of their job, as they talk to customers, get new ideas from Developers, change priorities, and measure the outcomes delivered by previous features. These activities influence the Product Owner’s thinking about priorities and details of the PBIs.

New ideas may be generated by the Developers too. And we don’t want to wait until the next Refinement Meeting happens to consider these new ideas. Waiting may cause delays, cause ideas to be forgotten, and leave little time for validation. Instead, refinement should happen at any time as needed.

Consider the following example:

A team receives a new PBI from the client. The PO had a first contact about it, and in the Refinement Meeting the team talks about it. The client is available, can answer questions (perfect world scenario) and the team considers three different options for how to develop it. All substantially different, with a different value attached and a different estimate for level of effort. Hence, each option would determine a different sorting for the PBI in the Product Backlog. All together, the team selects one of the options, and since the PBI sounds like a dramatically valuable item, the team together with the PO put it further up the Product Backlog, prioritizing it for the next upcoming Sprint. All good so far.

BUT:

During the night, the minds of some Developers continue working when they sleep, and in the morning someone comes back with a new idea about this particular PBI. It changes the situation and has impact on the estimate in a way that it may not be done in the next Sprint any more. And before the next Sprint starts, there is no Refinement Meeting scheduled any more. 
So one option is to keep the PBI as originally planned and do it in the next Sprint. 
Another option would be to consider the new idea and to clarify with the client right away whether the thought of the Developer is valid or not. In this case the clarification, which was caused by a novel design idea of a Developer, would be done in between Refinement Meetings, and hence, would be an activity.

This is another reason with the Product Owner is a member of the Scrum Team and not a separate entity. By working together with the Developers on a daily basis, the Product Owner ensures that the refinement of the Product Backlog is continuous, that context is shared, and that new ideas are taken into consideration as soon as possible.

The Product Backlog is never stale. It is continuously refined and detailed appropriately while new ideas emerge. In a sense, the Product Owner is the director of all of these activities.