Buffers and Placeholders in Agile SCRUM Project Management

In Agile SCRUM, upfront planning is done for the different phases of a project, outlining the minimum scope and the requirements for each phase. The Agile SCRUM methodology accounts for some planning in the process, with user stories, tasks, and requirements turned into tickets that become part of a sprint. There’s also the concept of a spike to explore different proofs of concepts or other ideas or to gather more information on requirements. Spikes are scheduled to dive deeper or to research potential solutions.

Time-boxing these spikes, or explorations, with finite time limits allows for spending some time exploring ideas, different approaches, and different implementations. A time box suggests that certain information should be gathered within three days, two weeks, or some other time limit before that approach is abandoned or accepted. However, this is only one of the tools that you can use to account for unknown time/effort.

As a project progresses, there can still be many unknowns and some uncertainty. The “Cone of Uncertainty” is a helpful concept to visualize the level of uncertainty in a project,

The Cone narrows only as you make decisions that eliminate variability. […] defining the product vision (including committing to what you will not do), reduces variability. Defining requirements—again, including what you are not going to do—eliminates variability further. Designing the user interface helps to reduce the risk of variability arising from misunderstood requirements. Of course, if the product isn’t really defined, or if the Product Definition gets redefined later, then the Cone will get wider, and estimation accuracy will be poorer.

Two proactive tools to manage this uncertainty are to use buffers and placeholders which address specific uncertainties by making time to handle them. The concept of the “buffer” is relatively underused in Agile and Agile SCRUM methodology. Many projects plan out specific tickets for work to be done, but there are still some unknowns.

Placeholders are tasks that say, “We need to investigate this,” “We need to do some research here,” or “We need to monitor and check in on some data.” They can be useful for marking maintenance or check-ins, re-evaluating past decisions, and adjusting the path forward. The benefit of the placeholder is that it ensures that critical parts of the project are completed. The placeholder is a simple check if the task is no longer relevant or has already been accomplished. If there’s still work to be done, the placeholder ensures there was time and effort available in planning to achieve that work.

A buffer is an additional task attached to a primary one. It is similar to time-boxing, where the buffer says we need to explore a specific idea. In most projects, this can take a few days to a few weeks. When estimating a long-term plan, this buffer can be used to extend or shorten the timeline. For example, software development projects sometimes involve setting up new infrastructure; however, it may be possible that at least some of the infrastructure already exists.

Buffers are a source of time and effort for conducting research, investigation, re-evaluations, check-ins, and monitoring. Each time a task related to the buffer is accomplished, the buffer becomes smaller, with less time and effort available for the subsequent investigation, prototype, or check-in. The benefit of the buffer is that it sets expectations on the time, effort, and scope of a project.