There Is No Room for Buffer With Scrum In Continuous Deployment

Scrum has a concept of buffer points. A percentage of the points that you are expected to ship in the next sprint that you can allocate for unplanned work and outside distractions. If the buffer is used up the sprint is busted and you hit reset. It is a bad thing when this happens. I put forward that this concept is a protection mechanism that gives the team the tools to make it clear why their project isn’t going to be delivered on time. Which makes sense when you are delivering a large project over a long period of time and the deliverables and feedback loops are infrequent and spread out and you are in a non-understanding environment of what it takes to deliver software. However, in a continuous deployment environment where you ship daily or multiples of it each day, the feedback is rapid and often, typically at least once per day, the goal is to learn and react, not block, and as such buffer puts a barrier up that is no longer needed, and quite possibly a distraction and unnecessary overhead. Further, if you are running a zero defect policy, which you absolutely should be, you don’t ever want a reason for your team to not immediately jump on a defect because the “buffer” is used up.

For all of these reasons don’t use buffer with Scrum in continuous deployment. Instead, track the found points percentage increase calculated as the number of points shipped and estimated remaining to ship the epic since the epic began over the original estimated points to ship the epic. If this percentage starts to swing too high then pursue scope negotiation, elimination and delegation of unplanned distractions to other teams. But don’t use buffer in the day to day decisions. It sets up the wrong mindset.