Why it is important to protect your sprint backlog?

by Leigh Espy

During projects, you know that change will happen. It is rare that you get to the end of an initiative and everything went exactly as expected. Agile practices allow the team to adjust to changes during product delivery. Agile also allows the team to adjust along the way based on feedback, new information, and unexpected needs. However, Agile does require discipline, and there are times when you say no to change. 

During the sprint, once the sprint backlog has been determined and the team is working on it, the scrum master helps the team stay focused on only that work. As the scrum master, you need to protect the sprint backlog as much as possible so that the team can complete the work that was targeted for this sprint.

Protecting the sprint backlog

If your team is not allowed to continue work on the backlog, you lose much of the value of the work done in sprints. The team goes back to context switching, losing valuable time and efficiency. The increase in works in progress slows the team down and destroys your team metrics in the process. Thus the team loses trust in the process.

There are many different types of activities that can disrupt the team as they are implementing the plan and working the planned sprint stories.

  • Fixing bugs
  • Emergency fixes or situations
  • Stories being larger than initially thought
  • User support requests
  • Administrative work
  • New work requested by stakeholders

How to address unplanned work in the sprint backlog

Explain the need for trade-offs.

If you are working on something, you should not be working on something else. If work was given a high priority when planning, then explain that if the team works on this new thing, they should not be working on something else that was considered important. Give visibility to the work so that the tradeoff can be better assessed. Take a look at all the stories and compare them with the new work being requested. Help the requestor, whether it be management or the product owner (on behalf of the customer), understand what will be pushed until later if the new request is moved in.

Build in capacity or buffer time.

If the team regularly experiences emergency requests, or increased need to focus on something outside of the user stories, then allow for it in your team’s capacity.

Say “no.”

There are times when you simply need to protect the backlog and let the team stay focused. This is not always possible. It is, however, worth looking at the proposed new work and assessing whether it merits taking the team from what was previously prioritized as most important. You may find this approach most valuable when stakeholders make regular requests to insert stories and do not seem to understand the importance of getting them in during planning. There is a bigger root cause here that needs to be addressed.

The need to improve stakeholder and customer understanding through coaching and training. Help them understand that the team wants to deliver what is important and valuable, and it can help to get this information sooner. This can also be a symptom of the team not being rigorous enough in the sprint planning. Take the time to ensure you have considered all the work needed and have done the appropriate level of planning needed.

Absorb the work.

This is not recommended as a long-term plan, but it might be needed in emergencies.

Spend time to understand the root cause.

Understanding the root cause will help you better address the true problem. If you have stakeholders who do not understand how to interact with the team, the problem will continue. If you have growing support needs that get bigger with each delivery of functionality, the problem will continue. If you do not take the time to do proper retrospectives to get insight into what is causing your problems, you will continually be reacting to them.

Consider the culture and environment. Does management fully support the integrity of the sprint? If so, you may be able to protect the backlog more easily. It may be that management is new to agile and accustomed to making frequent requests for additional work. If this is the case, and you do not see it changing soon, keep this in mind as you help them make the adjustment. Make sure they know the impact on the sprint and allow time for these requests. By understanding the root cause, you can provide coaching, training, better or more frequent communication, and better planning to improve the situation for everyone.

It is important to protect the sprint backlog to allow the team to focus on the work at hand more effectively. Take the time to address disruptions to this work, and help others understand the importance of protecting the backlog. Your team will appreciate the effort, and you will see better results.

 

Similar Content:

You may also like

Index