Backlog Refinement Challenges: Unreadiness and Reluctance
Even though the Scrum Guide does not particularly cover the product backlog refinement sessions, we are safe to say that these are some of the most common, but also crucial and challenging scrum events. Although the challenges in question differ from company to company, this article will be going into the problems that extend the time-box of the product backlog refinement session of hesitant Scrum teams by covering the following main topics:
- Not being ready for the product backlog refinement
This problem comes from a Scrum team that always has a full product backlog, but that cannot effectively refine product backlog items. This state creates an uncertain picture during sprint planning and causes the items to pile up in the backlog.
- Being too hesitant as a Scrum team
A Scrum team finds themselves in this situation when they want to make sure the backlog items are ready for every possible scenario. Typically they fail to agree on the tasks at hand, and they also tend not to give story point estimations since they take their time to try to remove all risk.
These two potential challenges unnecessarily lengthen the refinement sessions. And unless the team tackles them, it is almost certain that they will need multiple sessions of refinement during the sprint.
Before Product Backlog Refinement
At Insider, we work with OKRs. When the OKRs that teams will be working on are decided, we discuss the details of the OKRs and have an OKR Refinement session to make the sprints clearer for the whole team. That way, teams are able to see the dependencies, requirements, risks, and blockers to other components/teams clearly and take action accordingly. That is why the teams already roughly know what to work on before any Product Backlog Refinement session happens, and they have an estimated roadmap from the OKR Refinement session. To learn more about the OKR Refinement, please check one of our earlier blog posts here.
At this point, the entire scrum team is encouraged to create items when needed (tasks, bugs, backlog items, etc.). During the sprint, the backlog is starting to fill up with the items that have been created by developers, designers, QAs, and product owners as well as dependent tasks that are directed by another team. Therefore, there are many tasks to be refined during the refinement.
What should be done to be ready for the refinement phase?
1- Prioritize the backlog items
Before the refinement session, the team is expected to set the prioritization of the item by considering the risks, the urgency of the dependency (if there are any), the negative effects that the item causes, and so on. Refinement should start with the highest priority tasks.
If the team decides that the priority of the item doesn’t reflect reality, it should be updated during refinement.
There are some popular techniques for prioritization such as the Eisenhower Matrix as seen below, the Rice Model, the Kano Model, etc.
2- Clear Description
When a backlog item is created, it needs to be given a clear description for anyone who might see that item. Since the team’s perspective is very technical and clear, and it takes much more time to write detailed explanations which they have not planned to spend during the sprint planning, they tend to write a couple of words that could be reminding them of that item, however, once they come back to the task they are having a hard time to clarify the item. This causes confusion and sometimes ends up with having the same item every session over and over, which is time-consuming.
This does not mean that items need to be fully decided and clear before product backlog refinement. The whole purpose of the product backlog refinement session is to clarify those backlog items.
We encourage the teams to set the required capacities to create clear product backlog items and fill these items with a clear description according to their knowledge of the topic before the product backlog refinement phase. As the item becomes clearer during the product backlog refinement, they are encouraged to update the item for everyone to understand it.
3- Related or Dependent Tasks
Before the product backlog refinement session, any known related tasks (design, bug, epic, subtask) should be linked to the backlog item to fully see the picture. If there is a known dependency, it is highly important to state the dependent team or the person for that item and describe what the dependency is.
Once they are known and the item comes to the product backlog refinement session, how the dependency situation will be handled should be discussed within the team, and the team should clearly define their actions.
Other Tips:
- Make sure the items in the backlog are not duplicated
- State the tasks’ type (bug, design, development, analysis)
- Create subtasks if needed
- Do not hesitate to get in touch with your teammates if you have any questions about the items.
During & After Product Backlog Refinement
As mentioned above, during the refinement, the team prepares the backlog items for the sprint ahead and ensures that the items pass the Definition of Ready (DoR). The DoR can act as a checklist for the team to guide the backlog improvement process.
- During the session, start with the highest priority tasks first. Update their priorities if needed.
- Discuss each item’s description, requirements, risks, dependencies, and test cases. Note these down to make it visible for everyone, especially the dependent teams. Make sure that when you come back to that item a while later, you will fully understand what that item is about. Align the items and the details together as a team.
- Give estimates of the items (story points, t-shirt size). Do not try to be %100 accurate about this estimation. Keep in mind that this is an estimation not a certain time-box that the team needs to follow.
After the refinement session, refined items are ready to be picked up for sprint during sprint planning. If there are items left to be refined during the refinement, leave them since they do not pass the DoR yet.
If an item is selected for the sprint, make sure that it is ready for the sprint by validating it against the DoR.
If the item is refined but is not included in the sprint, track how long it stays in the product backlog.
Measure the backlog items’ age, and be aware of your backlog’s content.
Team Reluctance Affecting Product Backlog Refinement
Some teams have a hard time discussing the items and creating alignment on them because of various doubts.
They discuss the items in every aspect possible, scenarios that they might encounter, and risks that they can think of. Although these are healthy and encouraged discussions, questioning them for too long, and not being able to come to a conclusion is an important problem that needs to be fixed.
The reason behind this type of doubt and reluctance could simply be the fear of making mistakes. Making mistakes is a great way to learn how to do things the right way. Learning from mistakes and improving the way of working is one of the best ways to improve the team’s success. Without making mistakes, the team would not be able to learn from them and have a mindset to go a step further. This is called Fast Failed Culture, and it is embraced by lots of start-up companies worldwide. With the outcomes of design thinking, they expect to fail fast and learn fast.
Checkout IBM’s Fail Fast and Learn Fast article for further information: https://www.ibm.com/garage/method/practices/culture/failing-fast/
Scrum’s pillars of inspection and adaptation affirm that making mistakes is a natural aspect of the process. Inspection involves regularly checking work for errors or issues, while adaptation encourages teams to use these findings as opportunities for learning and improvement. This approach acknowledges that mistakes are part of the journey and vital for ongoing progress.
There is a fine line between failing and learning from failure. Teams should be encouraged to take risks and learn from failures however they should not fail all the time. To encourage them, Scrum Masters play a crucial role. Here are some tips that you might want to consider:
- Investigate the reasons behind the reluctance (have a workshop, survey, etc.)
In the example above, questions to bring up self-awareness might be asked to see how the team members see themselves and the confidence level they have for failing. Ask them on a scale of 1–5 how they feel about the specific topic.
From the purple circles above, it seems that this team makes mistakes however does not take reasonable actions to prevent them from happening again. They think that mistake will make them an unsuccessful team, and they want to avoid it. They need to be reminded that mistakes can happen, and it is part of the journey.
- Encourage them to take risks as long as they learn from them.
- Make sure the team takes actions and discusses them during retrospectives.
As much as this is a self-awareness issue, during the product backlog refinement session there are some final tips that can help you while too much questioning happening during the session:
1- Ask the team whether it is required to discuss that topic or if it is a detail that will not change the task’s scope. Make sure they are focused on the item itself.
As a Scrum Master or a developer who does not have enough knowledge about that topic, it is not possible to know if the team is out of focus. Ask yourself and the team if they started to question what instead of how. Raise your flag, do not hesitate to intervene.
2- Encourage them to give estimates. Remind them that the estimates do not have to be perfectly accurate and that they do not have to think about the worst-case scenario all the time.
3- Remind them that their growth and learning will be slow if they don’t take risks and potentially make mistakes.
If you have further questions, please do not hesitate to raise them here. You can also reach out to me on Linkedin.
Stay tuned for more news about us, and do not forget to check other blog posts from Insider Engineering. If you liked this article, you can also read the article written by Zhanara Kolbaeva that is shared here.
