Why it is important to protect your sprint backlog?

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.

1 2Next page

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button
Close
Close