Cycle time, queues, work in progress and batch size – four things product teams need to reduce if they want to deliver more value faster

Good product teams are focused on rapidly delivering maximum value to their users. This post describes four factors that when kept to a minimum, enable teams to deliver more, more often and at a higher quality: cycle time, queues, work in progress and batch size. In this post, I explain what these four things are, why reducing them helps teams become high-performing and some of the techniques we can use to keep them to a minimum.

Image of people cycling fast. See what I did there?

Cycle time

What is cycle time Cycle time is the elapsed time spent on a work item from start to finish. The stopwatch starts when work starts and ends when the work is finished, and includes any time in the middle when nobody is actively working on it.

Why we should try to reduce cycle time Shorter cycle times mean that we can deliver work items (aka value) to users:

  • faster
  • at a lower cost
  • at higher quality
  • with less risk

That last one about risk is one of the most important to me. Most of the time new features don’t fail because they weren’t usable or couldn’t be built. They fail because nobody wants to use them. The quicker we fail, the faster we can change our approach, and the lower the cost of failure. That is why “fail fast” is such a popular term in the software world.

The below images from The Agile Weekly show the relationship between cycle time, risk and batch size (which I will cover in more detail in the next section).

Batch size

What is batch size The size of a work item. Often measured in t-shirt sizes, or the amount of weeks it will take someone to do.

Why we should try to reduce batch size Reducing batch size refers to the practice of delivering smaller increments of work rather than large, monolithic releases.

Reducing batch size is probably the best way to reduce cycle time because smaller bits of work get done faster and are easier to troubleshoot if things start to go wrong. It’s much easier to find a needle in a matchbox than a haystack!

Big batch sizes can cause a lot of variability in queue times. Ever tried to get a train near Arsenal on match day? 60,000 people leaving the stadium all at the same time is a big batch that causes huge queues and slows down travel. Transport for London encourages people to avoid transport near stadiums on match days to reduce batch sizes.

How small is too small? A good rule of thumb is that each batch of work should deliver value or learning. Beyond that, the main limit to batch size is the fixed costs associated with each batch, which we should strive to reduce.

The below image from Boost illustrates how small batch sizes lead to smaller queues. Imagine each of those purple triangles representing a bunch of customers turning up at a restaurant and the amount of time they spend in queues. If loads of customers arrive at once, they’ll likely spend more time in queues.


What are queues Queues are the list of work items that are waiting to be worked on. In product development, they can exist in ideation, discovery, design or delivery.

Why we should try to reduce queues Queues can be very useful in small doses. If someone on the team finishes a piece of work earlier than expected, a small queue of well-defined and prioritised work means they can easily stay focussed on doing the most valuable thing.

Work items that are in progress but stuck in queues increase cycle time and work in progress. My biggest problem with larger queues is that they cause waste. As a product manager and general plan-a-holic, I am often tempted to get ahead of the team and start defining work months ahead of time. If not done right, this risks causing waste in multiple ways (I have been guilty of all of the below):

  • work stuck in queues for a long time is more likely to go out of date. Work that goes out of date represents wasted effort
  • when work is stuck in a queue for ages and it needs to be picked up again, it takes time to re-learn the context. Context switching is wasted effort
  • looking at long lists of things and wading through out-of-date documentation takes mental effort and makes it harder to focus on the actual priorities
  • psychologically, it sucks to have a huge mountain of tasks piling up in front of you. It can really demotivate people
  • me getting ahead of the team and defining work either means distracting team members from what they’re working on now, or doing work on my own that would be best done collaboratively by a cross-functional team

Work in progress

What is work in progress WIP (work in progress) are work items that are being worked on at the same time. For most of us in the team that means work that is in discovery or delivery.

Why we should try to reduce work in progress Most people work best when they do one thing at a time, fast and to a high-quality standard, before moving on to the next thing. Working on more than one thing at a time leads to:

  • more multitasking. It takes time for people to switch contexts, and increases the likelihood of error
  • higher coordination and management overhead, leading to confusion and delays
  • increased stress for teams, who can start to feel overwhelmed by the amount of work in front of them
  • slower cycle times and increased queues, with all the associated risks

How much work in progress is not enough? I have seen small teams achieve incredible success before by focusing on one thing at a time. This meant zero queues and fast cycle time, but a hell of a lot of mob programming (a great practice in small doses, but difficult to maintain all day every day). For most teams, 2-3 things would be a more realistic minimum. The key thing is for teams to pay attention to the inefficiencies too much work in progress can cause, and try to keep them to an acceptable minimum.

Techniques you can use to help

Cycle time, batch size, queues and work in progress are all closely related. Reducing one often reduces most of the others. Here are a few of my favourite ways to keep them at a minimum:


With any piece of work, try to identify the MVP. The MVP (Minimum Viable Product) is the smallest piece of work you can do to either deliver value or validate learning. My favourite example of a MVP is Dropbox. They didn’t start by building anything. They created a 4-minute video demo of how they imagine Dropbox might work. When 70,000 people signed up for their waitlist overnight, they knew they were onto something. They had validated their hypothesis that users would find Dropbox valuable at a very low cost, much quicker than they could have done by building something.

80/20 rule

The 80/20 rule is another obsession of mine. The idea behind it is that for any problem you are trying to solve, you can usually deliver 80% of the value with 20% of the effort. In any new feature or functionality, look for the smallest thing you can do to deliver most of the value. Focus on doing that thing as fast as you can. Once it is done, pause and reflect on what you have learned before doing the next slice of work. More often than not, you will learn something.

Visualising work

Viewing all work on a Kanban board makes it easy to see where queues are building up and where there might be too much work in progress. Both Notion and Linear support viewing work in this way.

Work-in-progress limits

Setting limits on the amount of work that can exist in a workflow stage at any one time forces people to focus on getting things done before bringing new work into progress.

Not planning for everyone to be 100% utilised

What does a motorway that is 100% utilised look like? Gridlock. Everybody is blocked by everybody else. A similar principle applies to product teams. Complex work like developing software is inherently unpredictable. Unanticipated impediments, blockers, bugs and requests pop up all the time. It is also collaborative. We often need to work with others on solving problems, reviewing work and giving feedback. We are also all human: people get ill, mistakes get made and family emergencies happen.

If we fail to plan for the unexpected, then we plan to fail. Assuming the team will operate at 100% results in a team consistently operating at above 100%. This leads to lots of waiting around, delays and multi-tasking (aka queues, cycle time and work in progress). More importantly, it burns people out.

When agencies bill out their people, they rarely plan for anyone being utilised at more than 80% (65% is apparently the average). Teams should try to leave slack capacity so that variability in workloads can be dealt with sustainably and to ensure the things they are focussed on doing get done fast.

The below image from AHA Moments shows that as people approach being 100% busy, the wait time for new tasks to be completed grows at a very fast rate.

Cross-functional collaboration

For complex work, groups of people with complementary skills working together on a single problem is usually the most effective way to work. Different people bring different things to the table. When you finish a piece of work, it often makes sense to ask anyone else if they need help or would like to collaborate on something that’s already in progress before starting on something new.

Focussed strategy

Good strategy defines the many things that the team isn’t going to focus on, and the few things that the team should focus most of their effort on. This enables the team to achieve maximum impact at pace with minimum effort. A clear strategy that is well understood by everyone helps keep people focussed on what matters and minimises the temptation to work on too many things at once.

Continuous improvement

Regular reflection by the team on how they can make their ways of working and their product better is essential. A culture of doing continuous improvement frequently and in small batches is unsurprisingly my preferred approach here. This is one of the reasons I am so in favour of teams doing regular retrospectives and being able to rapidly experiment with improvements.

Definitions of done

Having clear definitions of done helps us ensure work gets done to a high-quality standard. This minimises the likelihood of creating new work for the team further down the line, such as bugs, performance issues or generally slowing down future work. Testing, documentation, performance and measurement are some of the key definitions of done that teams should consider.

Infrastructure to support continuous delivery

Last but not least, to enable batch sizes to get smaller, we need to invest in techniques to minimise the fixed cost involved in making a change. DevOps practices like continuous integration and continuous deployment help teams make smaller changes to software at a much lower cost.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *