Cycle time, batch size, and planning horizons form a reinforcing system. Not only do large batches and long plans cause long cycle times, but also long cycle times cause long plans and large batches. It is entirely possible to attempt to implement small batch work, WIP controls, and short-horizon planning and still fail to see flow improve. Not because people don’t want to do it, but because cycle time is fixed by the organization’s architecture and process.
Streamlining the process and automating time-consuming manual labor are imperative in modern software shops. Perhaps even more important than attempting to reduce batch size and limit planning horizons.
Reverse Causality
Long cycle times cause far horizon planning and large batches when there is a complicated, multi-step process of handoffs between multiple approval agents and specialized silo teams.
Product managers will not find value in creating small experiments of short duration if the process itself is so ponderous that results will come months later. When the process is long and cumbersome, the smart thing to do is create a large batch of work to get results on as many things as soon as possible.
Such a system runs incredibly slowly because the process is a long and difficult road for a work item to walk. The batching and far horizon planning that inevitably result slow it down even more.
A terrible process is not only slow on its own. It causes the effect of slowing itself down even more. It is recursively slow. And, we need short cycle time, because…
Software Development is Uncertain
Fast cycle time is critical when faced with non-repeatable, creative, uncertain work.
Software development is uncertain. While the programmer may reuse subroutines to accomplish repeating patterns, the work itself is emergent and filled with uncertainty, as is any creative work. Even when you are building functions that exist in an old system into a new system, the work is still uncertain. The backlog will still be emergent, and variability and new learnings will come up along the way.
Creative work needs fast cycle times so that we can approach it empirically and humbly. I am writing an article to post on my site, and it is creative work. I have done it many times before, yet I cannot say at this moment what percentage of the article is complete. I will write far more than is finally published. I cannot estimate the completion of this article.
The speed at which small batches of work are delivered increases the frequency of learning from the customer and the work. Fast cycle time allows a team to remove uncertainty by doing the work.
Very Short Cycle Time is Possible in Software Development
Software can be easily changed or even deleted from existence by typing on a keyboard. This creates a competitive environment where it is possible to create something and deliver it in a day or even hours, learn from it, and pivot to a new direction. It is possible to establish a learning cycle with feedback loops so fast that the time taken to make a plan could instead be used to simply do experimental work.
Since my competitor probably knows these things, they will do the work to learn, and they will try to establish the fastest learning loop they can by speeding up the cadence of delivery. I must do the same or they will accelerate their understanding of the customer, market, and application at rates I can never hope to catch up to. Scrum and xP are designed to create this effect. Market conditions require speed.
Short cycle time is essential to survival and success. Delivering every six months equals death.
Shared Vocabulary
Before we explore the relationship, let’s ensure we are thinking the same things and sharing a vocabulary:
- Planning horizon – the length of a plan’s schedule.
- Far horizon planning is anything that reaches out into multiple months.
- Short-horizon planning is the next hour, the next day, the next week, the next sprint – and no further.
- Batch size – the size of a group of work items to be delivered.
- Large batch work happens any time many small things are forced to stay together in the process. Examples:
- any project,
- a requirements document followed by
- a comprehensive up-front design,
- a testing monolith that requires many things to submit simultaneously because the environment is singular and must be created on a schedule,
- a release with multiple items in it.
- Small batch work is when a single, valuable idea is allowed to move through the system independently of other items and flow from one end to the other without being stopped and waiting for others.
- Large batch work happens any time many small things are forced to stay together in the process. Examples:
- Cycle time – the amount of time between starting and finishing without regard to any idle time or other adventures the item experiences.
How Plans, Batches, and Cycles Reinforce Each Other
This is a reinforcing system, not a linear chain that exists in bi-directional relationships:
- Far horizon plans ↔ large batches
- Large batches ↔ long cycle times
- Long cycle times ↔ far horizon plan
When plans are made far into the future, batch size increases to fill the time allotted. As scope items join the plan, the probability of large releases goes up. The long plan itself causes batch size to increase which causes cycle time to lengthen.
The reverse is also true: when batch sizes are large and there is a group of scope items that must travel the system together and release together, the plan horizon will extend into the future, lengthening cycle time.
But there is another key insight.
Construction Style Project Management Persists
Project management comes to software development from the construction industry where it works quite well at managing a far horizon plan for known, repeatable work. Construction project management needs a RACI chart, a risk register, a charter, and change management committees because it is driven by contracts which are fixed fee with penalties and incentive payments attached for on-time, under-budget delivery at quality. Large construction projects inevitably result in multiple lawsuits, and in court, you need those documents and comprehensive plans to sort out who agreed to what and assign blame.
Practices that are rational in building the visible structures that make up our civilization fail to bring the fast learning needed to do creative work in an uncertain environment. In software development, these practices lock in long cycle times, force long plans, create cumbersome processes, and encourage large batches. They provide a sense of control, but they slow everything down dramatically.
Such practices and the cumbersome processes that emerge from such approaches must be remedied before meaningful results will emerge.
Streamline the Process
Most organization use Scrum, xP, SAFe, Kanban, or some other approach to try to speed delivery. Most of them have no measurable benefits from doing so. They are likely unaware of the relationship between already having a long cycle time causing people to have to employ strategies that make cycle time long.
Interrupt the status quo by starting to automate and remove steps that currently add time to delivery.
Many steps can be automated, and the industry standard today is to remove manual labor in these areas:
- Build – any activity of creating a package for deployment
- Deployment – the act of moving something from one environment to another
- Integration and Regression – most testing can be automated and should be part of coding
- Environment creation – environments are expected to be push-button on-demand for teams these days
- Test data acquisition – push a button and get the standard loadout which is a subset of production
- Release – release on demand allows the product manager to push a button and make something live. Or even the developers!
Manual work by teams in separate silos increases costs and creates queueing that slows everything down.
The process itself also requires remediation:
- Approvals – companies that work in far horizon plans and large batches have high-risk releases. Thus, there are many approval chains that must be completed before work is released.
- Self-management – Empower employees by putting them into self-managing teams where the product manager can approve their own teams’ work without excessive vertical communication.
- Redundant tests – Quality cannot be tested into software. There is little evidence that more testing improves quality. Automation improves quality. Large batch size also puts quality at risk by increasing dependencies and complexity. Reduce quality risk by working in smaller batches.
Conclusion
Remediate the process and automate your manual steps as much as possible, beginning at the right side of the process flow and work your way left. Then smaller batches and WIP controls will start to make more sense to you. You should still attempt them, but controlling planning horizons, WIP, and batch size alone will not get the job done.
My initial estimate for writing this article was two hours. It took three days. While writing it, I generated new ideas for the articles linked below that should probably be expanded upon or clarified especially around what batch size is.
Articles on this site which explains these three concepts individually:
Last updated 2026-02-17