How DEEP Backlog Refinement Can Save Your Squad
Learn how to build a DEEP backlog and conduct productive refinement calls in order to maintain a happy and agile team.
Let's start with a reflection. The questions to follow will help you understand if your team is or not suffering from the structural problems caused by a poorly refined backlog:
- Is your team able to finish the user stories within the sprint, or are the stories frequently dragged from one sprint to another?
- Is the work well distributed throughout the team, or are some overwhelmed while others with too much spare time?
- When a sprint starts, are all team members able to work on their tasks right away, or do some already start the sprint blocked by personal doubts about the work, missing requirements, or even waiting for final decisions from the business team?
- How long do the planning sessions last? Do they feel long and tiring? Do you feel that you as product manager are a crucial figure during the planning? Or is the technical lead aligned enough on the upcoming sprint items to conduct the call?
What did you learn from answering the questions above? If your answers give you cause for concern, you probably need to do a better job refining your backlog and conducting a backlog refinement meeting.
A not well refined backlog causes many problems for the team. As the owner of the backlog, you need to create some distance between the features and user stories that you are defining and the user stories going into the sprint. When these problems highlighted by the questions above happen, is usually because the backlog is either too short, meaning the product manager is always rushing to get everything defined before the sprint starts, or the stories are already defined, but haven't been discussed enough with the developers.
The DEEP backlog
Roman Pichler discussed the idea of a DEEP backlog with his article Make Your Product Backlog DEEP. In order to create a DEEP backlog, you need to be always ahead of development, having time to define your stories and discuss with the team a few sprints before it actually goes into development.
If you are always in a race with the development team, to have stories ready and defined sprint by sprint, then you won't have time to improve the quality of the backlog, and the snowball will become an avalanche. The first step into fixing your backlog problems is to create some depth, and for that the backlog refinement calls will play a key role.
The backlog refinement call
For every meeting, be it recurring or not, it is very important that there is clarity around what is considered success for that encounter.
In the backlog refinement's case, I really like the definition of success proposed by Maria Chec in the article Refining the Refinement. Backlog refinement basics:
The goal is to achieve a shared understanding of the work that will be done and that each team member is aware of the scope and nature of the tasks they will face in the next sprint.
Even though it is clear that the act of refining a backlog is a constant work and responsibility of the product manager it is specifically during the refining meeting that the features and stories are shared with the team, that contributes according to their role. In my experience this is how each member of the team should play their part in the meeting:
Developers
The developers role in a backlog refinement call are the following:
- Clarify all the doubts regarding the business logic and requirements. Make sure the items being refined are 100% clear to them;
- Define what will be the implementation strategy of the items being refine;
- Question the product manager on what is extremely necessary for a first release (must have) and what can be broken in smaller stories and prioritized for future iterations (should have);
- Map of there is any definition, dependency or blocker that needs to be solves before the story can be considered ready to develop.
In some cases, the implementation discussion can take longer than expected. For these scenarios, it is important to recognize it is a complex task, and that it might require another meeting dedicated to discuss its technical implementation.
Quality assurance engineers
During the refinement call, the QA engineers have the duty of:
- Verifying if the PM forgot to mention any flow or functionality that can or will be impacted by the new development being discussed;
- Verifying if the PM contemplated all possible scenarios during the user's journey through the new functionality;
- Listing all test cases that will need to be considered;
- Evaluate if the proposed new development will require regression tests.
Data engineers
If your team is equipped with data engineers, they can help with the following:
- Verifying if any new data is being added to the database that should be mapped and synced with the data lake.
- Check if all metrics the PM wishes to track to evaluate success of the new release are already available. If not, help the PM plan how to make this data accessible.
Product designers
I would say there may be different opinions in the industry about rather product designer should or should not be part of the backlog refinement call. And there is an even bigger divergence about rather the product backlog contemplates design work or not, and if the designers are part of the sprint or not.
In my experience so far, having worked at three different companies, all doing product and development in a slightly different way, designers should be close to the developers and QA engineers, but their worked should not necessarily be tracked inside the sprint. Product designers often are responsible for all UX responsibilities, from research to prototypes and UI designs, making it complicated to break down their work as we would break down a feature that is already defined.
For this reason, I prefer to have the product manager and product designer aligned and working closely together, guaranteeing that even if the product designer don't attend refinement calls, they have a clear understanding of the backlog and their priorities. In my opinion, most of the time they won't benefit or contribute as much to the backlog refinement call, making it more valuable to have them focus on their tasks.
In some cases, when the design is a huge part of the new feature, meaning we are adding new components or interactions to the code project, that were not yet documented in the design system. In these cases it is valuable to bring the product designer into the refinement call to help clarify any doubts and even understand if the frontend team needs any adjustments to the screens in order to deliver on time.
How should product managers conduct a refinement call?
Your work begins even before the call starts, making sure you have worked at least on the D (detailed) and P (prioritized) of your DEEP backlog.
You should come to the call with already a clear idea of the next few sprints priorities, and the highest the priority, the most detailed the user stories and features.
As the person responsible for conducting the refinement, your role is to go over each of the highest priority items of the backlog and repeat the following steps to each of the items:
- Share the story with the team and make sure you mention three key aspects: the motive behind the story, the requirements, and how success will be measured. If the story is part of an entire new feature/epic/release, then first give a broader context of what we aim to build before jumping into the stories.
- Once you have shared all key aspects of the item, invite the team to share their understanding, ask questions, and propose implementation strategies.
- Continue to guide the discussion between the squad, making sure each team member is playing their expected role in the item refinement, until the story is 100% clear to all, with a definition of done and with the developers being satisfied with the size of the story. Note that many times, during the discussion, a story will be broken down into smaller stories or sub-tasks.
It is likely that during the discussion the team realizes that a story needs more research and defining, or that it is blocked by an external dependency. In these cases, it is the PM's role to understand that it might be best to re-prioritize other items, and come back to this one when it is indeed ready for a tech discussion.
As leader of the ceremony, it is very important that you pay attention to the timing of the call, to make sure all tasks that need to be discussed for next sprint have been covered. As your team grows mature in backlog refinement, you will be refining two or three sprints ahead, instead of always refining tasks of the next sprint. This is great maturity, as it guarantees that a sprint will never be jeopardized because of lack of defining or refinement.
Once you have achieved this maturity, you will start each refinement meeting with already a few sprints of refined and even roughly estimated user stories. When this is the case, usually the team starts the call by quickly going over the already estimated stories, to make sure there are no new learnings or changes in priority that might require new estimation or reprioritization.
What is the ideal frequency of a refinement call?
I believe this frequency will always vary according to the teams maturity and depth of backlog.
In my experience, teams that already have achieved this maturity, and that are already refining a few sprints ahead, will be very safe and comfortable with one refinement call per sprint, which is the frequency proposed by SCRUM. It should also not take more than one hours per week of sprint (if a sprint has one week, your refinement call should be max 1 hour, but if it has two weeks, than the call should have no more than 2 hours).
When a team is still reaching for this maturity, sometimes they might require longer and/or more frequent refinement calls, only until they are caught up. If that is your case, just be careful to get caught up fast, as long and frequent calls are very bad for your teams health.
Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.
