5 Practical Ways to Help Optimize Backlog Refinement

Many Scrum teams suffer from sprint planning meetings running too long. And even after a long planning meeting, backlog items still aren't "ready" to be implemented smoothly during the sprint. Consequently, it’s hard to get backlog items fully "done" in time. On the other side of the spectrum, some teams are handed backlog items for which a lot of analysis and design work has already been conducted. This allows no room for teams to explore their own solutions for particular business needs.

Scrum teams need to prepare backlog items for future sprints. This is called backlog refinement. Items for the next one or two sprints need to be "ready." But getting backlog items ready is not a goal in itself. Only just enough is needed to be able to get backlog items to "Done" smoothly during a sprint.

A balance must be realized in terms of how much, how far ahead, and how collaboratively backlog refinement is done. You must continually inspect and adapt this balance.

In this article, I'll list five powerful tips to optimize backlog refinement:

1. Development teams must understand the business domain.

2. Development teams must know the road ahead.

3. Not all backlog refinement should be done in plenary meetings.

4. Non-team members should not do backlog refinement for a team.

5. Frequently reevaluate how backlog refinement is done.

Development teams must understand the business domain

One of the keys for doing backlog refinement well is to ensure that a development or scrum team gains a good understanding of the business domain. In many companies, the thinking is that development teams need to understand only the technology, and the product owner and stakeholders need to understand only the business domain. Often, development teams are perceived as mere "builders" of solutions that have been detailed by others. Having architects, designers, and business analysts excluded from development teams is a common symptom of this thinking.

All team members should have direct contact with end users and other key stakeholders to create good solutions for business problems. This helps them identify alternative solution strategies, make better trade-off decisions, and depend less on a product owner to feed the team detailed backlog items. Too many teams create products with only a vague idea about the end users, because they don’t collaborate with any of them.

Often, there is no direct contact between team members and stakeholders because of fear that teams will work on whatever people ask them to do. The product owner needs to balance the requests of multiple stakeholders. But this should not imply that team members have no direct contact with stakeholders. They need to defer to the product owner only if requests are made for other things than currently prioritized, or if gold-plated solutions are requested.

Development teams must know the road ahead

Development team members should have a good understanding of the road ahead from a business point of view. Which stakeholders are going to be satisfied with future product increments? What are their needs? What are the main solution ideas? What is the plan for upcoming releases

Only when all development team members are involved in looking ahead to future sprints will they develop a sense of care and shared ownership. There will be less risk of team members making short-term decisions that make future changes unnecessarily hard. And the product owner can better manage stakeholder expectations about future deliveries.

Many teams estimate backlog items only for the next one or two sprints. They don’t discuss and estimate less refined, longer-term items. Often this is because of the way estimates are treated. If teams feel that an estimate is interpreted as a commitment, they are not willing to estimate backlog items that are not yet refined in detail. But it is much better to already have a rough estimate for future backlog items than no estimate at all, especially because estimating involves multiple perspectives on trade-offs, solution alternatives, and dependencies.

Not all backlog refinement should be done in plenary meetings

Many teams do backlog refinement only in sessions with the whole team. However, if vague ideas are discussed for which many things are unknown, these meetings often get out of hand. Before a team can start to implement things, many details need to be known about business needs and technical possibilities. But exploring details causes meetings to take longer, thereby disengaging participants. Since team members have more interesting and challenging work to do than attending dreadful meetings, they quickly start to hate these sessions.

You need to create a balance by involving all team members, on one hand, and not spending too much time in meetings, on the other hand. Estimates for backlog items for future sprints are given in refinement meetings by the whole team. But if further research is needed, it can be done outside of these meetings. The team can agree on which members will do it. In a later meeting, the more refined backlog backlog items can then be estimated.

This approach has several advantages. Since the team collaborates on who will work on refining items, deciding which individual will work on which item depends on the nature of the refinement work itself. For example, if technical aspects need to be researched, certain members might have more interest; if business process details need to be researched, other members might do the research. And because the research work is done by members of the development team, there is no handover from others back to that development team.

Related Article: 6 More Tips for Backlog Refinement 

Non-team members should not do backlog refinement for a team

In many organizations, business analysts and designers are separated from development teams. They prepare backlog items. Development teams estimate only items that are small and clear. Teams can focus on implementation without having to spend time discussing unclear business requests.

While this may seem to be an efficient approach, a handover of ready backlog items to a team that gets them done has many disadvantages:

• Contextual information gets lost.

• Team members don’t give their input in time.

• Bad short-term decisions are made because a long-term perspective is missing.

• Teams feel less ownership of the work that they do.

• Suboptimal solutions for stakeholders are created because developers don’t speak with them.

Refinement should be done by a development team in direct collaboration with the product owner and stakeholders. It is perfectly acceptable if some members spend more time on refinement than others. For example, a team might include interaction design as part of what "ready" means to them. Then, an interaction designer might work on designs for future sprints. However, just like the rest of the team, she is only done with a backlog item when it is fully implemented. The team will evaluate over time if the upfront design effort needs to be more, less, or done in a better way. The team might find out that it works better if the designer creates only a rough sketch and then sits together with a coder while it is implemented.

If there are many teams, there is an even bigger risk that teams won’t collaborate directly with stakeholders. It is therefore important to organize teams so that they can focus as autonomously as possible on a particular business domain.

Frequently reevaluate how backlog refinement is done

What works well today might become a problem tomorrow. Therefore, we frequently need to reevaluate how we do backlog refinement.

For example, consider a team that got blocked several times by having to wait for design decisions. Then a change is made: A designer will work one sprint ahead. Development goes more smoothly after this change. However, in time it causes other problems. The designer reaches an agreement with the stakeholders on designs that turned out to be hard to implement. The team decides to design more collaboratively instead of leaving it only to the designer. A while after that improvement, again change is needed. Designs often needed to be redone because of changes in insights by stakeholders. So the team needs to learn how to do less upfront design before an item is considered ready for a sprint.

The direction for optimizing backlog refinement should be to attempt to do as much work as possible in the sprint itself. Find ways to minimize the need for upfront analysis and design. For the upfront work that remains, ensure that it is done in close collaboration between team members and stakeholders.

No one solution works best in all contexts. Even in the same context, there is no solution that will continue to always be the best. Teams mature in their grasp of technology and business domain, team members change, stakeholders change, etc. Therefore, teams need to continuously reevaluate how much, how far ahead, and how collaboratively backlog refinement is done.

Related Article

Article: How to Integrate Bug Fixes in you Backlog

======

About the Author 

For more than a decade, as a Scrum coach and trainer Marco Mulder has had a positive impact on countless organizations: small start-ups, large companies and governmental organizations. Many people have told him that he not only helped to improve the speed and quality of the work at their organizations, but also their joy and sense of fulfillment at work.