How to Calculate Cycle Time?
To calculate cycle time, you need to determine the total time it takes to complete one cycle of a process or task.Â
General Formula to Calculate Cycle Time:
Cycle Time = Total Production Time / Total Number of Cycles
- Total Production Time: This refers to the time required to complete all the necessary steps to produce one unit or complete one cycle of the process.
- Total Number of Cycles: This represents the total number of units or cycles produced within a specific time frame. It could be the number of units produced in an hour, a day, or any other defined period.
Why is Cycle Time Important?
Cycle time is a good indicator of not just the health of your software projects, but overall engineering effectiveness as well. Quick delivery of features loosely translates into quicker revenue, better cashflow, and a healthy bottomline.
Moreover, shorter cycle time is also an indication of streamlined workflows where devs aren't just firefighting anymore. Short cycle times keep your team engaged, motivated, and churning out their best work, leading to higher engineering productivity, and well-being.
Here's why cycle time matters to engineering teams:
1. Slower Time To Market, And Fear Of Losing Out To Your Competition
Every day a feature sits locked in development is a day your competitors are leaving you behind. Amazon was losing out on 1% of their sales before they amped up their cycle time to reduce deliveries from 6 hours to 10 minutes. Imagine the lost opportunities and stagnant growth associated with a sluggish cycle time.
The market moves fast, and slow teams miss out on capturing emerging opportunities. Moreover, your rivals get to users first, potentially shaping market preferences, and you stand with a potential threat of being locked out. On top of it, missed deadlines and delayed features damage customer trust and brand reputation, there you lose your CX advantage to your competitors.
2. Poor DevEx
Long waits for deployment, testing, and feedback breed frustration, disengagement, and eventually, burnout. Studies show a 27% rise in burnout rates for teams with lengthy cycle times. This frustration spills over, even tanking the morale of the overall engineering team. A high cycle time means the team isn't able to diagnose the impediments that are blocking the devs from doing their best work.
When things move slowly, it's easy for devs to feel detached from the impact of their work.
3. High Rework, and Code Churn
The pressure to "hurry up and get it done" breeds hasty, poorly-written code. This becomes a vicious cycle: rush to deploy, encounter bugs, rewrite code, repeat. All in the bid to control an inflated cycle time.
This technical debt translates to future bugs, constant firefighting, and delayed releases. It also means your features stand at the risk of becoming obsolete or irrelevant, improving the instances of wasted effort and resources.
Cycle time is not just about speed. It's about balancing speed with quality and ensuring you're delivering critical features to end customers.
Impact of High Cycle Time
Risk of Code Quality
When cycle time is high, a natural eventuality is for more work remaining in a work-in-progress status. As sprints close and deadlines loom, engineers end up juggling between several unfinished tasks, increasing the risks of errors and writing buggy code. At the same time, the longer it takes to merge code, the more context is lost by authors. These incidents impact code quality and increase the chances of missing edge cases. This is a vicious cycle, when it takes longer for engineers to revisit the code after review, the longer it takes to fix the code, in turn increasing cycle time.
Risks to Delivery
Increased cycle time inevitably leads to tasks overflowing sprints that delay delivery. As sprints remain open over time, it leads to several critical tasks remaining unfinished and hence impacts the speed of delivery for the team. Furthermore, the effort to review and rewrite incorrect or inefficient architecture or poor code, the loss in context due to long gaps to pick up reviews, and the context switch between WIP tasks caused as a result of high cycle time severely impact the productivity of the entire team and the quality of the code.  Â
Bad Employee Experience
As code stays in WIP status, engineers shift between several tasks, increasing context switches and the associated lull in productivity. As the habit stretches, engineers find themselves context-switching between different git branches and pull requests while working under the pressure of delivery timelines from the product team.Â
In most teams, cycle time increases are attributed to the bottleneck caused by reviewers. As more review requests pile up, it adds to the pitfalls of context switches, poor workload management, and threatens well-being. These circumstances compound into individuals feeling increased stress, anxiety, exhaustion, and eventually burnout.Â
When engineers and their teams work under such pressure, within a matter of time, they begin missing schedules and deadlines, often delivering code that underperforms. This leads to team members feeling unsatisfied, often impacting engagement and morale.
[Read: How to Delete a Branch in Git]
Drawbacks and Problems of an Extremely Short Cycle Time
Though a cursory glance at a very low cycle time metric for a team might be an initial reason to be buoyant of the team’s performance, managers and leaders must pay attention to such instances. In almost every case of very low cycle time, which is lower than industry averages, we see that the time to review is considerably low. For engineering leaders, this is a potential “gotcha” moment since very low cycle time could be a possible signal of low-quality code reviews. Managers must implement checks and workflows that ensure thoughtful and detailed reviews for all PRs. Â
What Are the 7 Factors That Cause High Cycle Time?
While managers and leaders are cognizant of the importance of cycle time, they aren’t always equipped with data for visibility into why their team’s cycle time might be higher or lower than optimum. Understanding the processes that constitute cycle time and delving into the components that make up cycle time can help leaders make decisions that positively affect developer happiness, productivity, and overall team performance.