Six Tips For Better Product Backlog Refinement Meetings

Product Backlog refinement (PBR) meetings are some of the painful and most unproductive interactions visited upon a Scrum Team.  If your Scrum Team feels that PBR is a painful chore to be endured, here are some ideas to lessen their pain and to help the team do better Scrum.

Product Backlog Refinement Defined

According to the Scrum Guide, “Product Backlog refinement is the act of breaking down and further defining [larger] Product Backlog items into smaller more precise items.”  Contrary to how most Scrum Teams practice Scrum, PBR is not a meeting (or in Scrum Guide language, an event.)  Rather, PBR is considered to be an “ongoing activity to add details, such as a description, order and size,” to existing, incomplete Product Backlog items (PBI).

If PBR is an activity rather than a meeting, what causes it to occur?  It occurs any time the Scrum Team receives new information, feedback or useful insights.  This information may come from other members of the Scrum Team, stakeholders, customers and/or end users and results in one, or more, of the following actions:

• Add, remove or update PBI;
• Add, remove or update an estimate (or size);
• Reorder the Product Backlog;
• Split PBI that are “too big” to complete in a single Sprint into “smaller” PBI;
• Document any technical tasks that the Scrum Team may need to implement; 
• Identify any dependencies that might exist among the PBI, or 
• Add, remove or update acceptance criteria.

Considering the list above, PBR is a fairly benign set of activities that pretty much all software teams do at some point or another during the development process.  Because Product Owners are accountable to manage the Product Backlog, it made sense that they would periodically prune the Product Backlog to keep it clean and crisp.  Therefore, early Scrum practitioners considered PBR a Product Owner accountability.

How Product Backlog Refinement Became Something Else

However, if you look more closely at the list above, there are activities that Product Owners would know very little about.  Estimating the size of PBI, identifying technical dependencies and documenting technical tasks are activities reserved for Developers.  In order for Product Backlog to be an accurate snapshot of what needs to be done, somehow the Product Owner would need to engage with the Developers to fill in the missing information.

To resolve this tension, early Scrum practitioners proposed a solution: Product Owners and Developers would have a meeting to exchange information.  That way the Product Owner would have access to the information they needed and Developers would be told in advance what PBI were being considered.  Ideally, this dialogue would allow Developers to influence the direction and design of the product. 

So far, so good…but notice the subtle change.  What started out as an individual accountability for Product Owners was recast into a Scrum Team accountability.  Creating more opportunities for collaboration is consistent with the Spirit of Scrum, so adding a new meeting could work for some Scrum Teams.

Where Product Backlog Refinement Got Lost

Two concepts came together that changed what was intended to be dialogue about co-creating the product into an awful meeting to be endured.

1. Early commitment: if you ask people what is the purpose of PBR, they might say, “to commit to detailed requirements, estimates and acceptance criteria.”  Except that’s not true.  Sprint Planning is where commitment happens, not PBR.  And whatever commitment is made is made to the Sprint Goal, not to detailed requirements, estimates and acceptance criteria.  The idea of making an early commitment is a residual of the Industrial Mindset (aka waterfall.)  However, if you believe that the purpose of PBR is to make commitments, then a lot of time would be spent arguing and negotiating over the details I mentioned at the start of this paragraph.  Instead of using PBR conversations to co-create the product, PBR becomes a zero sum negotiation with Product Owners and Developers on opposing sides.  And if a Scrum Team’s performance is evaluated on how well they “meet their Sprint commitments,” then the stakes of this negotiation can be very high.
2. Definition of Ready: while this practice could be helpful to some Scrum Teams, there seems to be a lot of confusion on how it intersects with Scrum.  To begin with, the phrase Definition of Ready (DoR) does not appear in the Scrum Guide. DoR is a practice some Scrum Teams use to ensure that both the Product Owner and Developers had completed some amount of lightweight, pre-work prior to accepting a PBI into a Sprint.  It was NEVER intended to introduce a gate to the development process.  However, if you believe the purpose of DoR is to create an enforceable standard to accept or reject PBI, then once again PBR becomes a high-intensity negotiation between Product Owners and Developers.

How to Fix Your Product Backlog Refinement

IMO, these two shifts are why most PBR has created so much negative energy within a Scrum Team.  Here are six tips to improve your PBR discussions:

1. Dial down the intensity: PBR (or Sprint Planning) is not about negotiating the end of a war.  Product Owners and Developers are supposed to be co-creating the product together.  Therefore, PBR is an opportunity to collaborate and discover the best solutions for customers, end users and stakeholders.  Save the high-stakes negotiations for another day.  
2. Not everything is a meeting: Developers have a lot to do during a Sprint and their work requires a great deal of concentration and focus.  If the Product Owner can gather the necessary information via email, Slack or a short conversation with one or two people after the Daily Scrum, that should be the default approach.  Meeting time during a Sprint is precious, so be careful how you use it.
3. Be selective on who attends: if you need a meeting, don’t invite everyone.  A lot of Developers simply want to know what they need to work on and are not that interested in how the sausage was made.  Instead of inviting the entire Scrum Team, bring together the Three Amigos (or whoever wants to attend.)  Use a smaller group to do the advanced thinking to ensure that work items are “ready” for Sprint Planning.  A pleasant side effect of having a smaller group at PBR is that the discussions will be deeper and more interesting.
4. Create an agenda: if you are going to interrupt a person’s day with a meeting, then the meeting organizer must prepare an agenda.  One of the biggest complaints Developers (and managers) have about meetings is that they are poorly organized.  Preparing an agenda ensures the meeting organizer designs an experience to maximize collaboration.  Another way to improve your agenda is to identify what PBI will be discussed and if any prework is required.  An additional benefit of making a list of the PB to be discussed is that it allows the meeting organizer to ensure the right people have been invited to the meeting.
5. Publish the agenda: another complaint Developers have about meetings is that no one tells them in advance what is expected of them during the meeting.  To address this issue, publish the agenda in advance of the meeting.  This will give the Developers time to think, to decide if they really need to attend (sometimes they don’t) and complete any necessary prework.  The more prepared people are for the meeting, the better conversations you will have.   
6. Only discuss items that are truly new: the meme “this meeting could have been an email” has teeth because it’s real for a lot of Developers.  To avoid this pattern, I recommend that you use PBR to talk about PBI that are truly new or unusual.  If PBI touches a topic, technology or business domain that Scrum Team is already familiar with, reserve that discussion for later.  For business-as-usual (BAU) topics, there is very little benefit to discuss them prior to Sprint Planning.  Therefore, save these conversations for Sprint Planning.  By deferring BAU topics to Sprint Planning (where you have up to eight hours), you create more time in PBR to talk about the items which need deeper discussion.

Enhancing the efficiency and morale a Scrum Team often hinges on eliminating their pain points.  Helping a Scrum Team recognize PBR as an ongoing activity rather than a burdensome meeting can help create a shift where Product Owners and Developers co-create the product.  By implementing strategies such as creating and publishing agendas, selective attendance and prioritizing discussions, Scrum Teams can optimize PBR sessions and drive more successful outcomes.