Sitemap

Spillover Zero

5 min readJan 5, 2022

--

Press enter or click to view image in full size

You’ve heard of Inbox Zero. Let’s work our way to #SpilloverZero.

Spillover provides feedback on the sprint planning process and sprint execution. The amount of spillover and the reasons behind the spillover are insightful indicators of improvement opportunities to accelerate forward progress. Follow along for the top 3 sources of spillover and how to address each one to deliver time and cost impacts to your customers.

1. Excessive Work in Progress

A large number of open work items means the team may be attempting to tackle too many workstreams at once. This will almost always slow down productivity for a developer and will often materialize into spillover. With more work in progress comes more frequent context switches, more unexpected bottlenecks, and more hidden dependencies. As a result, the overall quality of the deliverable can take a hit and the customer might have to wait longer for a feature. There’s a value loss from things taking longer to complete — it delays realizing business value.

In most cases, it’s better to postpone starting a work item to focus on finishing work items already in progress. The team may have overestimated their work capacity for a sprint or underestimated the effort required to complete a work item. In either case, it’s important to limit the number of concurrent work items to reduce context switches.

WIP limits can control the number of projects or the number of work items in every sprint. For example, a WIP limit could require a developer to not have more than 2 work items in progress at the same time. Another WIP limit could restrain the sprint to just focus on 2 ongoing projects. But whether it’s 2, 4, or 10 is completely up to the dynamics of your team. Prioritize. Decide what’s most important within your business objectives and focus on delivering value against those objectives.

2. Unanticipated New Work

New work can show up unexpectedly and derail a sprint. The product is down and needs to be recovered ASAP. Database performance is slow and needs to be investigated. The SVP is requesting last-minute due diligence before a purchase order. These are high-priority work items that you or your team will need to jump into quickly. But what happens to all the other planned work? It gets put off and is likely to be a source of spillover. With an unexpected shift in priority, lower priority work had to be moved to address pressing business needs.

You’ll never be able to account for everything so it’s advantageous to prepare your team to accommodate shifts in work priorities. One of the compelling value propositions of Agile development is to encourage responding to change over following a plan. The key is to make sure that urgent issues are not pulling people away from other work too frequently. Unanticipated work does increase uncertainty and decrease predictability — which makes it even more difficult to achieve consistency in sprint output.

One way to achieve a more responsive team is to reserve team capacity to handle the unexpected. From queuing theory, once a team is above ~80% utilization, the wait times (queue size) for work items increase exponentially. So as a general rule of thumb, blocking off at least 20% of time across the team will help to ensure work items are not backed up, and new work can be handled without grinding existing work to a halt.

Get Ryler Hockenbury’s stories in your inbox

Join Medium for free to get updates from this writer.

As a way to allocate for reserved capacity, some teams have point persons (or on-call persons) to triage and respond to high-priority requests. Other teams may bake reserve time into each week through “20% time” policies. Or at sprint planning, the team can allocate reserve time for each person — see my post on sprint efficiency for more on this.

3. Hidden Dependencies

Not all components of every work item have to be perfectly defined before starting work. But be careful! When non-trivial lurking dependencies are hidden and only exposed after starting the work, it increases the chance of spillover into the next sprint — or creates unexpected new work for other teams.

Team A may release a breaking change to an API that Team B was dependent on. Now Team A has to roll the change back or Team B needs to make updates to their code. Another example is when work requires specific expertise. Forward progress is then gated until someone with the right skills is available. Some symptoms of hidden dependencies include high coordination costs between teams and cases of change cascade (multiple unexpected changes resulting from a single change).

There are a number of methods for combating hidden dependencies. First and foremost, revisit the planning and scoping process for work items. While it’s tempting to jump right into new work, a structured (but lightweight) planning effort can highlight the rough edges and curb surprises. Focus on identifying prerequisites, cross-team coordination needs, and verification criteria (the test plan).

Second, if your planning process is in good shape, then construct more ways to surface potential dependencies. Daily team standups provide a good forum for calling out blockers. Take a few minutes with the team during sprint planning to walk through each work item and consider anything that might slow the work down. Once a potential bottleneck is revealed, take action to correct it.

Lastly, if you are still encountering frequent surprise dependencies, build a dependency map for each work item. This adds overhead but will force the team to think through the work comprehensively to tease out everything that the work touches. To cement dependency mapping into a team habit, you may need to require that a work item cannot be started until its dependency map is created and peer-reviewed.

Wrapping It Up

With all that said, it’s important to always balance spillover with other objectives. Value, quality, and speed should never be shortchanged to just push a few more work items into the done column. Treat spillover like a metric. It can provide insight into the deficiencies of a sprint but it’s just one metric. Balance is key to shaping a sustainable pace and staying aligned with your business initiatives.

Hope to see you next time.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author.👇

This article was originally published on December 20, 2021 at rylerhockenbury.com [https://www.rylerhockenbury.com/blog/spillover-zero]

Follow me on Twitter.

Let’s connect on LinkedIn.

Check out my Blog.

--

--

Ryler Hockenbury
Ryler Hockenbury

Written by Ryler Hockenbury

I help organizations to better utilize data, technology, and people. Follow me for posts about DevOps, Serverless, Cloud, Productivity, and Agile.