Sprint Backlog Strategies

Kanban Board

Many Scrum teams incorporate Kanban boards to make their work more visible and easier to manage. A Kanban board (sometimes known as a Scrum board when used by a Scrum Team) is a visual management tool that helps teams track work items as they move through various workflow stages. The most common usage is to visualise the Sprint Backlog. Almost all the Scrum Teams I have worked with since 2005 used this simple practice. A Kanban board can also be used to visualise the Product Backlog.

When the work in a Sprint is visualised via a Kanban board, every Scrum Team member and their stakeholders can more easily understand the status of Product Backlog items and tasks. This can increase trust and reduce the burden of progress reporting. Progress during the Sprint will be visible in real-time via the Kanban board.

The Kanban board can be especially useful during the Daily Scrum, where the Developers plan the next working day. Instead of relying solely on verbal updates, the Kanban board offers a shared point of reference to guide the conversation and help the Developers better understand the work and their plan. This can help foster a sense of collective responsibility. As tasks move across the board, it should be clear to see which tasks might need additional resources or support, where bottlenecks might be forming, and how close they may be to achieving the Sprint Goal. This can lead to enhanced collaboration, with Developers more likely to offer assistance, share expertise, or plan and work together to ensure work moves forward. The visualisation can help illustrate that regular, visible progress is being made, which can help to motivate the Developers.

Buffer For Expected Unplanned Work

Leaving a buffer for expected unplanned work in the Sprint Backlog acknowledges the inherent uncertainty of complex product development. Unexpected challenges or needs often emerge. Where these can be anticipated ahead of time, a helpful practice can be to allow a buffer of unplanned time for each Sprint to handle this reality.

An example of expected unplanned work would be where a Scrum Team is supporting a live system whilst developing. There may be regular support requests that require attention. Whilst these may not be known ahead of time, we can predict that they will emerge, so leaving some time for each Sprint to handle them can be an effective tactic. Some Scrum Teams allocate a percentage of capacity to handle this work. Other allocate a specific Developer. Either way, this approach has some benefits and is widely used.

By allocating a buffer within the Sprint Backlog, means that when support work arrives, it can be addressed without completely derailing the Sprint and preventing the Scrum Team from achieving the Sprint Goal. Moreover, ensuring there’s room to accommodate unexpected tasks helps maintain the quality of work by avoiding overburdening.

Having a buffer also plays a psychological role, enhancing team morale. Continual failures to meet Sprint Goals can erode the team’s confidence and reduce stakeholder trust. By contrast, when buffers are in place, the team can more smoothly handle unplanned work.

Buffer For Uncertainty

A variation on the buffer for expected unplanned work similarly uses a buffer to allow for other forms of uncertainty. When a Scrum Team is newly formed and developing a new product, there will be many unknowns, and their ability to plan accurately will likely be low. Leaving a buffer of unplanned time each Sprint to absorb some of the uncertainty and change likely to emerge can be a good practice in helping the Scrum Team.