Recipe for a good Product Backlog Refinement
Andrei Ulasau
Andrei Ulasau
What is Product Backlog Refinement?
According to the Scrum Guide , Product Backlog Refinement is a continuous process whose goal is to improve and specify the scope of the product (in such a way that the development team is able to work on it effectively).
Product Backlog refinement is the activity of dividing Product Backlog elements into smaller, more precisely defined units and specifying them more precisely. It's a continuous process to add details such as description, order and size. These properties often vary depending on the specific nature of the work.
- SCRUM GUIDE
Good Refinement, or what?
The criteria we use to assess the quality of refinement certainly depend on the specificity of our project, its goals, process, individual preferences, as well as a number of other factors. My (I believe quite universal) most important functions and refinement goals are:
- building team awareness of the project scope and product roadmap ,
- uniform understanding of the scope by the entire team,
- obtaining feedback from the Product Owner/stakeholders (team's opinion on the scope of the project),
- establishing a common (technical, business, organizational) strategy for implementing tasks in the backlog,
- equalizing competences in the team and building a sense of responsibility for the scope of the project,
- estimating the size of work/tasks for effective planning.
And in this order. Someone might say that there is little orientation around the product scope itself. Maybe - but that's how I see refinement. As an excuse for the team to sit together, learn to cooperate, understand the scope of the project assigned to them and agree on what and how they intend to do - together, as a team - to plan and implement it in the future.
15 ways to improve refinement
Below I present a handful of good practices and ideas for conducting and improving refinement.
Before meeting
- Publishing the meeting agenda/refinement plan with min. one day in advance . The team is obliged to familiarize itself with the planned issues, initially (individually) verifying their completeness, noting doubts and suggestions. This allows you to save valuable time on refinement and focus on the most important topics. The agenda is published by the person responsible for shaping the issues in the Product Backlog - e.g. an analyst / Proxy Product Owner.
- Preparatory mini-refinements , held regularly (e.g. once a week), with a limited team (e.g. analyst + 2 team members, selected on a rotational basis). Their goal is to initially verify issues in the Product Backlog and technically prepare them for refinement (e.g. editing descriptions, acceptance criteria, converting User Story to Spike, etc.) - so as to save the entire team's time on proper refinement.
- Definition of Ready (DoR, readiness criterion) is a set of rules adopted by the team that determine when a given Product Backlog issue is ready to start work. Its aim is to reduce problems during development, resulting from, for example, insufficient description, failure to perform dependent issues (de facto blocking the task being performed), lack of appropriate projects (e.g. graphic interface). Of course, the failure to meet all points does not prohibit the discussion of a given issue in refinement (after all, this is where some DoR criteria should materialize), but it gives the team an indication whether the task is ready for a broader discussion.
Definition of Ready ( = the issue has been developed and is ready to start development work)
1. The task description does not require translation, and the business context and purpose of the task are included in it,
2. The task contains acceptance criteria,
3. The task contains the elements necessary for its implementation execution, including graphic design, translation keys, accesses, etc.,
4. Dependencies with other tasks are recognized and recorded,
5. The task has been discussed and understood by the entire team,
6. The team has estimated the size of the work,
7. The task has been given appropriate attributes in the design system (component , version, epic),
8. The task has been marked with the status "Ready for development".
During the meeting
- Refinement cannot be too long . According to MeetingKing.com data , in the case of a 15-minute meeting, we can count on the concentration of 91% of participants. In the 45th minute of the match, this value drops to 64%. Later it only gets worse. For this reason, I avoid refinements longer than 1 hour (although I once participated in a project in which refinements lasted the whole day!), usually using two permanent, 60-minute refinements a week + additional meetings, organized as needed.
- The meeting is led by two people . One responsible for the scope (Product Backlog elements to be discussed), e.g. Product Owner or analyst. The second one - e.g. Scrum Master - is responsible for the effectiveness of the meeting, its moderation, activation of participants, organizational support, implementation and monitoring of the adopted rules. I do not recommend combining both roles during refinement. Even if it is technically possible, it is a very exhausting practice for the trainer. It may also negatively affect his relationship with the team (he will become a bit of a "boss").
- To help the Product Owner or analyst familiarize the team with the assumptions of individual tasks, it is worth engaging a rotating assistant for this purpose . He is obliged to thoroughly prepare for the presentation of topics on the meeting agenda and to co-host the meeting. This significantly relieves the burden on people responsible for the Product Backlog, increases the attractiveness of refinement and the sense of responsibility for the scope among members of the development team.
- By definition, the entire team participates in the meeting , but depending on its agenda and course, it sometimes happens that some specializations are exempted (by the Scrum Master) from the need to be present in selected parts (e.g. UX designers during conversations about IT infrastructure or BackEnd security). This allows you to optimize refinement costs and maintain focus.
- We start the conversation about each element of the Product Backlog by locating it on the product roadmap . So that the team is aware of the importance of the topic, the functionality of which it is a part and the possible time horizon. This introduction is handled by the Product Owner or analyst.
- 15 minutes on one topic - our team adheres to the rule that we do not devote more than fifteen minutes to one topic. This reduces long-winded discussions and boredom and brings the topic down to its essence. The Scrum Master monitors the passing time and moderates the discussion accordingly. If an issue cannot be fully discussed within 15 minutes, it means that it requires preparation for another refinement (we then decide what needs to be done/explained before the next meeting).
- Note: in my opinion it is very good (it is even necessary!) for a complex issue to go through several refinements in this way. Only then can we be sure that it has been properly thought out and understood by the entire team, i.e. that it is a mature requirement.
- Using abstract measures to price tasks , such as Story Points or T-shirt sizes, significantly facilitates and speeds up the estimation process. The team does not waste time wondering about the exact value (e.g. 7 hours) - which is probably not adequate anyway - but rather strives to determine the relative size of the issue. I feel much more at ease with it. In my experience, abstract measures are paradoxically more accurate than absolute ones.
- The voting method (Planning Poker) is perfect for task valuation - when each team member, after prior discussion, independently declares their own estimate of the issue. I recommend two tools here:
- Planning Poker cards – resembling playing cards, perfect for on-site meetings when the whole team is together,
- PlanItPoker – a great, free online voting tool (based on playing cards), ideal for virtual meetings in a distributed team.
- When estimating tasks, we strive to achieve consensus . We do not average the values given by the team, but we discuss them, trying to understand each other and choose a common front, sometimes repeating the vote several times. As I mentioned earlier, for me refinement is in many ways a pretext for a team conversation about the scope. Valuation is not an end in itself here.
- User Stories are now widely used in almost all agile and quasi-agile projects. Properly constructed and complete (see the section on Definition of Ready) they are a very light and effective carrier of requirements for the team.
- "Spike" (research) issues are a good idea when the topic is unclear, requires further exploration, and the final result is not fully defined. Instead of reading the tea leaves and wasting the team's time on blind attempts, it is worth conducting research - with a specific and achievable goal. We will perform the actual task after reviewing "Spike's" results
