A recurring challenge for software development teams is dealing with unplanned work. Even with the best planning techniques in place (sprint planning, backlog grooming, etc) it can be very difficult for a team to be prepared for the changing business priorities.
As a Scrum master or team lead you could say no to your business stakeholders with any new business request that potentially could interrupt work in progress, but that is not always the most responsible approach.
After all, the point of adopting “agile” is to make it easier for a team to respond to change.
Rather than hoping that unplanned work with not happen, embrace the idea that it will happen. Do this by reserving capacity for unplanned work.
- Start by calculating sprint points based on a projected 10% improvement increase from current team velocity and 30% buffer for unplanned work. This buffer will also help a team deal with reduced team capacity, such as someone on the team going on vacation during the sprint:
-
sprint points = ((team velocity *.10) + team velocity) * .70
- For example, if team velocity is 35; then sprint points the team should commit to in the sprint would be:
- 26.95 = ((35 * .10) + 35) * .70
- For example, if team velocity is 35; then sprint points the team should commit to in the sprint would be:
-
- Then during the sprint strive to not add more work than the allocated 30% buffer during a sprint.
- For example, ~12 points (11.55 = ((35 * .10) + 35) * .30) should be the max points added mid sprint for unplanned work. Such as for incidents or scope changes.
Carlos Gabaldon 