Does your Scrum Team need to Buffer Sprint Velocity?
Consistent Sprint Velocity is key to predictable delivery in the real world. If your team’s Sprint Velocity is erratic, it’s hard to determine what to bring into the Sprint Backlog and to meet your Sprint commitments.
Not all scrum teams have the luxury of only working on new development. If your team supports production applications, emergencies may occur that divert the team’s energy. If this happens on a regular basis, it no doubt wreaks havoc on your Burndown. By introducing the concept of a Sprint Buffer, which consciously reduces the number of Story Points brought into the Sprint, the team acknowledges the reality of production emergencies and this helps level out Sprint Velocity.
How does a Sprint Buffer Work?
First, analyze your team’s performance over the last 6 Sprints.
On average, by how much does the team miss its Sprint commitment?
For example, let’s say your team believes they have the capacity to complete 32 Story Points each Sprint. If your team regularly commits to 32 Story Points, but consistently closes only 26 Story Points and the 6 point miss is because the team is sidetracked by production emergencies, you can face reality and attempt to stabilize Sprint Velocity by giving the team a 20% Sprint Buffer. Reduce the next Sprint Backlog to 26 Story Points. If few or no production issues occur, you can always bring in additional Stories.
Second, track the Sprint Buffer as part of your Sprint statistics.
Every time a team member gets assigned a production issue or emergency to work on, add a Buffer Story to the Sprint Backlog. Do not assign the Buffer Story any Story Points or assign it zero points, because it does not contribute to your Sprint. At the end of the Sprint, record the number of unplanned Buffer Stories completed by the team along with Sprint Velocity as part of your statistics.
Combine Bugs with Project Work in the Backlog
Review every Buffer Story the team is asked to work before adding it into the Sprint Backlog. Is the issue truly an emergency? If the issue is not System Down or there is a workaround to the problem, put the issue into the Backlog as a Bug.
At Story Grooming, size the Bug along with the Stories written by the Product Owner. With a combined Backlog, both new Stories and Bugs can be planned for and brought into Sprints. This technique also helps reduce the Sprint Buffer, while increasing predictability.
Why should planned Bugs get Story Points? This forces the team to think about the level of effort required to fix them. Depending on your Sprint goals, your Product Owner now has the luxury of weighing the amount of development work that must be completed in the upcoming Sprint against the business need to fix high-priority Bugs.
Review the Sprint Buffer Every 3-4 Sprints
The number of production issues worked on each Sprint can vary widely and be unpredictable. Plus, now your team is working on both Bugs and development Stories pulled from a combined Backlog. Every 3-4 Retrospectives, review the number of Buffer Stories that truly require immediate resolution and adjust the Sprint Buffer if needed.
Acknowledge Sprint Buffer Risk to Release Dates
I realize that reducing the team’s capacity appears to dramatically increase the risk that your team will not meet its release dates. But, you already had the same risk, when you missed your Sprint commitments on a regular basis.
Now, however, if your team is on a tight schedule, you raise the realized risk to management and the Sprint Statistics explain the cause. Enlist management to help your team decide criteria for Emergency (work now) vs. Backlog (work when have time).
I’d love to learn how your team manages production issues with project work. Do tell.
Cynthia Kahn
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500