Photo by Marcos Araujo from Pexels

What Waiting in Line Teaches About Your Quarterly Planning Process

Years ago, I joined a startup that was building towards the initial launch of their first product. They had a vision and had been working towards an initial release for nine months already and had about six more to go. Looking back on this, I should have been more horrified by these timelines, but it took me longer than it should have to recognize what was wrong and why. Reflecting back, there are a few basic principles of Queueing Theory and Lean Product Development that, had I known them at the time, would have led to better outcomes.

Queueing theory is the study of waiting in lines. By applying mathematics to model the behavior of queues, we can predict useful things, such as wait times. This concept of queues applies in different ways as we zoom in and out of the product development process. There are company backlogs, team backlogs, individual backlogs, cross-functional initiative backlogs, and more.

Each of these behave differently, but are governed by underlying principles, allowing us to better understand and optimize our choices. For the purpose of this post, we’ll limit ourselves to looking at queues as they relate to planning an engineering team’s project backlog and do our best to avoid diving into the specifics of how they can affect individual projects or tasks (although that is equally fascinating).

In this post, we’ll look at three rules to keep in mind when planning a quarterly backlog* (or whatever your longer-term planning cadence is):

1. Queue depth kills
2. Variability is reality
3. Small batches solve problems

At the highest level, the goal of quarterly planning is to select a set of projects for a team that maximize the value delivered, while minimizing the cost to deliver that value. If creating value in product development were simple and predictable, the team could simply graph products using hours of effort vs. value created and pick a backlog to minimize that ratio. Unfortunately, the details of delivery and value creation matter, and they matter a lot in determining success of your backlog. Let’s look at each of the three rules above and see how they apply here.

Queue Depth Kills

When I say queue depth in this context, I’m referring to the number of items in your backlog. Having a long list of projects you want to accomplish isn’t problematic in-and-of-itself, but it can create side effects which can be.

Inventory Rot

In a factory, having inventory laying around is obvious, it takes up space and decays in value over time (either literally, figuratively, or both). In the digital world, this is harder to spot because it doesn’t take up physical space, but it does take up mind space and screen real-estate (see the next section on Management Costs). Another problem is that products change. If I design a great feature to manage billing rules and it sits in my backlog for a year waiting to get prioritized and the industry regulations change, I will have to rework that entire set of stories and design. This means my initial efforts did not produce value, and in fact, pulled value away from something else I could have been working on that did create value.

Management Cost

Upkeep on a queue is not free. Even if you are always keeping the highest-value items at the top of the queue to avoid increasing lead time for important projects, having 100 epics and 1000 stories in your backlog means you (or your Product Manager) have to consider those items every time you search through your list to find the right things to work on. Additional organization can help this, but keeping things organized isn’t free either.

Never-ending Work

Large queues of work can create motivational challenges for teams. If a team keeps working on a never-ending backlog where completion never seems to get any closer, this can be very frustrating. I like to refer to this type of project work as Driving through Kansas. The team knows it’s moving, but the landscape never changes. This is partly an issue with oversized queues, and partly an issue with creating a story and milestones for the team to see their progress.

Large queues are also demotivating to Product Managers and Designers who know that the work they do is just going to sit in a queue for months after they finish it. If the work goes immediately on to the next phase of production, it is far more motivating to finish it.

What to do about it:

Managing queue depth takes attention, but there are a few things you can do to avoid the costs of queues.

• Keep long-term planning lightweight until you need it. As a project nears the point where your engineering team will start work, the fidelity of your planning should increase. You should also not be spending a lot of time planning things which are far in the future. How many of your plans from last year would be usable, unchanged, right now?
• That time is likely better spent on a project which is closer to engineering work beginning. That said, spending a day to understand the project at a high level will help you plan for the future.
• Create milestones for your backlog: to avoid the feeling of Driving Through Kansas projects, find ways to create distinctive moments in time for the team. This could be pausing to celebrate small wins or creating milestones for larger projects.
• Clean your backlog. Just like the adage, “if it’s important, it’ll come up again”, you don’t need to write down every small idea or bug that you encounter, just the ones you’re going to work on in the near future.
• Work in small batches (see below).

Variability is Reality

Variability can mean many things. In this context, I’m referring to unexpected changes in delivery timelines or value created. Variability in delivery timelines are a fact of life in software projects — scope is discovered, engineering challenges come up, customers change their minds. You can seek to minimize, but never fully eliminate this. The value of a given product change can also be hard to pin down. I may initially believe that a given feature will save 100 hours of time annually for our operations team, but in reality it only saves 10 — or maybe it saves 150.

Aside: While variability is almost always negative in a manufacturing context, it’s worth noting that it can be positive in the product development context. Maybe your engineering team finds a way to build a project in half the time, or a feature you thought solved one problem can also be used to solve two more. Because of the costs and potential benefits of variability, it’s important to understand how it works in product development and to plan accordingly.

There are a few principles to understand when it comes to managing variability so you can optimize your plan to your team’s specific needs.

Software Queues vs Manufacturing Queues

In a typical manufacturing system, once a product is designed, the goal of production is to produce the same product over and over again. In product development, value is created by changing an existing system. This can have lots of unexpected results, rendering software development more prone to variability than manufacturing.

Capacity Utilization

One counter-intuitive and important aspect of capacity planning is that your queue size gets worse exponentially as your utilization increases (as slack reduces). This is due to the compounding likelihood that any given task has to wait in a queue before work begins on it. Fully booking your team’s time removes slack from the system, and a full system will have a harder time responding to the unexpected.

One real-world example of this occurred a few years ago when one of the two elevators in our office building broke. Despite losing only 50% of elevator capacity wait times increased by 10–100x. The wait times for the elevator went from near-zero to 60 seconds or more. Why did this happen? With two elevators, there was excess capacity, meaning that queues didn’t form and there was often an elevator waiting in the lobby as the other delivered people to their desired floors. When one elevator broke, there was no longer excess capacity for the elevators, queues formed in the lobby, because the single elevator was busy delivering people to upper floors.

This effect of capacity usage leading to high wait times is made even more extreme when your tasks have high variability in completion time (like most software projects).

Adding a new item to the queue will have an effect on the overall queue and cycle time that is proportional to the steepness of the line at that point. Adding an unexpected unit of work to the queue at 75% capacity utilization will have far less effect on queue size than at 95% utilization. The system becomes less tolerant to the effects of variability as utilization increases.

This applies to quarterly planning as well — how full you plan your team’s time will dictate how much the variability of projects will lead to delays in your plans. Higher planned time utilization (less free time planned) means less slack to account for variability. This leads to exponentially growing queue depth and increased completion times — there isn’t enough slack time to catch up to the plan.

While it may seem that planning for 100% capacity use (being busy every day of the quarter) would lead to optimal efficiency, it creates a brittle system susceptible to variability in your plan. Building in excess capacity to account for variability will improve plan’s resilience and your odds of on-time delivery.

Buffers Aren’t Free

It’s worth noting that by adding a buffer to your team’s goals for the quarter, you may be accruing extra cost. Let’s say, for example, that I am coordinating the launch of a new feature with our marketing team. Marketing has to do ad buys far ahead of time, so needs a definite date from me. Rather than planning my team at 100% capacity, I instead add some buffer to the deadline. This means I give marketing a date which is eight weeks out instead of six. Assuming that my team could have delivered in those six weeks, that means we lose two weeks of value generation from the ads due to the delay. This can translate to real dollars lost for a business. It’s worth considering this cost when negotiating plans for a quarter (or any other deadline) and likely means that there is some level of risk worth assuming when setting deadlines. However, given the negatives above, it’s often worth planning extra capacity.

What to do about it:

Just because variability is unavoidable doesn’t mean you shouldn’t seek to reduce costs from it.

• Shifting risk reduction from high-cost to low-cost project phases reduces the cost of variability. Pushing risk reduction earlier in the project’s life cycle typically accomplishes this. For example:
• It is much easier to iterate on a design than a finished product. Doing initial usability testing with wireframes before building is faster and cheaper than doing it with production (or even prototype) code.
• If the engineering needs of a project are complex, iterating on a design document before writing code is often a much faster and cheaper way to reduce risk.
• When planning a team’s capacity for the quarter, you can buffer variability by allocating people to interrupt-driven work, such as being on-call. This allows you to plan some percentage of your team’s time to be removed from your quarterly planning capacity in exchange for fewer interrupts for the rest of the team.
• Determine if increasing delivery timeline accuracy is important for your team’s situation. If it is, consider planning your backlog for more slack to reduce the effects of variability on completing your plan.
  Knowing how much time to plan as slack for a team is an inexact science and depends on knowing the cost of being late and the likelihood for variability (for example, new teams or low-quality code tend to have more variability). You’ll never get this perfect, but use previous quarters’ results to calibrate your team’s needs so you are improving each quarter.
• Work in small batches (see below).

Small Batches Solve Problems:

As you’ve probably noticed, small batches are potential solutions to each of the above problems. Let’s talk then about changes you can make to dramatically improve your outcomes. If you’re not already doing so, here are a number of benefits to splitting large projects into smaller milestones. Shipping early and often has its advantages.

Faster Learning

If you build a feature for two months, you are making a gamble: staking that time on a bet that you are solving a problem in a way that generates high value for your users. If you’re wrong, you lose all or a portion of those two months of your team’s work.

In my experience, every project is imperfect and could have been improved if the team had had more information up front. What if, instead, you build for two weeks and then test your assumption with users? This would let you check your direction for the remainder of the project, de-risking the continued investment and allowing you to change course to a more valuable one. Because these learnings affect future work, that future work is then more valuable, which then affects the future, and so on. The benefits of faster learning compound over time, meaning small improvements lead to big outcome effects.

The analogy I like to use for this is constructing a brick building. To create this building, one piles bricks and mortar in layers on top of each other to form the whole. Without checking if the bottom layers are correctly positioned and set, the high layers of the building can’t be known to be structurally sound. The best way to verify that the foundational layers are the right ones is to test them with reality. In my analogy, that could be a firm kick to the wall. In the software world, this often means deploying to production, where your users can kick and see if your solution works for them. If you have a 10 foot wall and a user knocks it over, that’s a lot of wasted work. If it’s a foot tall, it still sucks, but you can now build it again better, knowing more than you did before.

Small Batches Reduce Risk

If a thread of work is open for a long period of time, surface area for risk of unexpected internal or external changes grows. Imagine your team is responsible for an area of product that is prone to bugs which need immediate attention. Assume that, on average, these bugs occur once/month. If I have a batch size of 2 weeks, the likelihood for any given 2 weeks of work being delayed by a bug is roughly 40%. However, if my project spans 2 months, the likelihood of one or more delays more than doubles to nearly 90%, and the cost of delay is now applied to the full 2-month batch of work instead of 2 weeks.

Time to React Reduces Variability

At the risk of sounding obvious, one way to avoid disruptions to your plan is to plan for them. In their book Accelerate, Nicole Forsgren, Jez Humble, and Gene Kim note that their research showed that gathering and implementing customer feedback is statically predictive of: higher software delivery performance, organizational performance, improved organizational culture, and decreased burnout.

As you plan your quarter, it can be tempting to fit as many pieces of work as possible into the quarter. If however you fail to account for responding to learnings as you go, you will be forced to make a trade-off between not responding to customer feedback (and the benefits listed a moment ago) and delaying the items already in your queue (leading to the negative consequences of large queues). This time consuming and difficult situation can be largely avoided if you plan time to follow-on to feature releases.

What to do about it:

• Work in small batches. Spend the planning time required to break larger efforts down into smaller pieces. If it’s not possible to ship portions of a large project to production, at least find ways to show them to a set of test users far in advance of the final release.
• Plan time for follow-on work. If a feature will take the team 4 weeks of the quarter to build a version 1.0, plan time into the schedule to do a follow-on 1.1 version. This will lead to a better product, will be more efficient because the team already has the context in their heads, and will reduce thrash on your roadmap.

Conclusion

If you want to lead teams that deliver high-value to your users, understanding queue depth, variability, and small batches is critical to find the right process for your situation. Start with asking these questions:

1. How long is our backlog? Could we trim it? Where else might we have inventory rot in our process?
2. Are we Driving Through Kansas? How can we create more awareness of progress?
3. What impact is variability playing in our success? Should we adjust the slack in our system to account for it?
4. Could we work in smaller batches? How could we work towards this?

Try making changes incrementally and monitor results. As you find things that work and things that don’t, seek to understand why they worked or why they failed. As you apply the underlying concepts behind the theory to real-world situations, you will develop intuition about the world that will pay dividends into the future. You can’t predict the future, but you can plan for it.

Good luck and feel free to leave a comment if you have any questions! Thanks to Rachel Stedman, Kyle Munkittrick, Shreyas Jayanna, and Sharon Delaney for their amazing editing and feedback on this post.

*Note: I realize that the idea of doing quarterly planning (as opposed to just-in-time planning) is somewhat problematic when it comes to keeping queue depth low. However, it is often a necessary compromise in an organization that requires coordination with many moving parts, as it allows batching of planning/communication work that would be very expensive to coordinate otherwise.

Thanks to Donald Reinertsen’s Principles of Product Development Flow for greatly deepening my understanding of all this. If you want to dive deeper, check it out!

Incidentally, researching this post led me to discover this blog post on queues, which is great and interactive: https://teropa.info/blog/2016/04/02/a-dash-of-queueing-theory.html