Also called: Cycle Time, Throughput Time, Flow Time, and Elapsed Time
Relevant metrics: Throughput, Quality, Cost, Customer Satisfaction, and Cycle Time
How to calculate Cycle Time:
Cycle Time = End time - Start time
What is Cycle Time
Cycle time is the total amount of time it takes to complete a single cycle of a process or operation. It is typically used to measure the efficiency of a process or operation and is often used as a metric for performance. Cycle time can be used to measure the time it takes to complete a single unit of work, such as a customer order, or the time it takes to complete a single step in a process – like fixing a bug, gathering customer evidence, or from writing the first line of code until its out in production.
By tracking cycle time, teams can identify bottlenecks, measure progress, and make data-driven decisions to optimize their workflows.
Where did Cycle Time come from?
The term “cycle time” originated in the field of manufacturing, where it was used to measure the time it takes to produce a single unit of a product. Specifically, cycle time refers to the amount of time it takes for a production line to complete one full cycle of manufacturing, from the start of one unit to the start of the next unit.
In the manufacturing context, cycle time is often used as a measure of production efficiency and a key performance indicator for the manufacturing process. By measuring cycle time, manufacturers can identify bottlenecks and inefficiencies in the production line and make changes to improve throughput and reduce production costs.
In recent years, the concept of cycle time has been adopted in other fields, including software development and product management, to measure the time it takes to complete a unit of work, such as developing and releasing a new software feature. By measuring cycle time in software development, teams can identify areas where their development process is inefficient and make changes to improve their speed and efficiency.
How Cycle time is used as a performance measurement for various teams
By tracking cycle time, teams can identify bottlenecks, measure progress, and make data-driven decisions to optimize their workflows.
Here are examples of how cycle time can be used to track and optimize performance for different kinds of teams and purposes:
- Continuous product discovery. Cycle time is also a critical metric for teams practicing continuous product discovery, which involves rapid prototyping, user testing, and iterative development. By tracking cycle time, teams can experiment more quickly, learn from user feedback more effectively, and make data-driven decisions to guide their product development process
- Agile and lean teams. Cycle time is often discussed in the context of agile and lean methodologies, which emphasize continuous improvement, rapid iteration, and fast feedback cycles. By reducing cycle time, teams can deliver features more quickly, respond to user feedback more effectively, and improve the overall quality of their product.
- Development teams. In software development, cycle time can be used to track the time it takes to develop and release a new software feature or product. By measuring cycle time for each stage of the development process, such as coding, testing, and deployment, development teams can identify bottlenecks and inefficiencies in their process and make changes to improve their speed and efficiency.
- Sales teams. Cycle time can also be used to measure the time it takes to close a sale and onboard a new customer. By tracking the cycle time for each step in the sales process, from lead generation to deal closure, sales teams can identify areas where the process is slow or inefficient and make changes to improve their performance.
- Support teams. Cycle time can also be used to measure the time it takes to resolve a customer support issue or request. By tracking the cycle time for each support request, support teams can identify areas where they can improve their responsiveness and reduce the time it takes to resolve customer issues.
- Product teams. In product management, cycle time can be used to measure the time it takes to develop and release a new product or feature. By tracking the cycle time for each stage of the product development process, product teams can identify areas where the process is slow or inefficient and make changes to improve their speed and efficiency.
- Onboarding time. One key metric for customer success teams is the time it takes to onboard a new customer and get them up and running on the product. By measuring the cycle time for each step in the onboarding process, customer success teams can identify bottlenecks and inefficiencies and make changes to streamline the process and reduce the time it takes to get new customers up and running.
- Renewal time. Customer success teams are often responsible for managing customer renewals, which involves working with customers to ensure they are satisfied with the product and are likely to renew their subscription. By measuring the cycle time for the renewal process, including outreach, feedback collection, and negotiation, customer success teams can identify areas where the process is slow or inefficient and make changes to improve their renewal rates and customer retention.
- Feedback time. Customer success teams often work closely with customers to gather feedback on the product and incorporate it into product development. By measuring the cycle time for the feedback process, including outreach, feedback collection, and analysis, customer success teams can identify areas where the process is slow or inefficient and make changes to improve their ability to gather and analyze feedback.
Factors that affect Cycle Time
There are several factors that can affect cycle time, including the complexity of the process, the number of steps involved, the resources available, the quality of the inputs, and the amount of time allocated for each step. Additionally, external factors such as customer demand, market conditions, and competition can also have an impact on cycle time.
Here are some typical factors:
- Team composition. The composition of a team can significantly impact cycle time. Teams with more experienced and skilled members will typically have shorter cycle times. On the other hand, teams with members who are less experienced or who lack the necessary skills may experience longer cycle times.
- Process design. The design of a team’s processes and workflows can also affect cycle time. Teams with well-designed, efficient processes that minimize handoffs and delays will typically have shorter cycle times. In contrast, teams with poorly designed or inefficient processes may experience longer cycle times.
- Tooling and technology. The tools and technology used by a team can also impact cycle time. Teams that use modern, efficient tools and technology that streamline their work and reduce manual effort will typically have shorter cycle times. In contrast, teams that use outdated or inefficient tools and technology may experience longer cycle times.
- Team communication. The level and quality of communication within a team can also affect cycle time. Teams that have open, frequent communication and collaboration will typically have shorter cycle times. In contrast, teams that have poor communication or collaboration may experience longer cycle times due to misunderstandings and delays.
- Workload and capacity. The workload and capacity of a team can also impact cycle time. Teams that are overburdened with work may experience longer cycle times due to delays and backlogs. In contrast, teams with a manageable workload and sufficient capacity will typically have shorter cycle times.
- Product complexity. The complexity of a product or feature can also affect cycle time. More complex products or features may require longer development and testing times, leading to longer cycle times. In contrast, simpler products or features may have shorter cycle times.
- Hand-overs. Hand-overs between different functions can actually increase cycle time within software development teams if not managed effectively.
Reducing hand-overs between functions to reduce cycle time
When multiple functions are involved in the development process, hand-overs become necessary to transfer work from one function to another. For example, design work may be handed over to the development team, and development work may be handed over to the testing team.
However, if the hand-overs are not well-managed, they can lead to delays and inefficiencies, which can increase cycle time. Here are some common issues that can arise with hand-overs:
- Miscommunication. When hand-overs are not well-communicated or documented, misunderstandings can arise, leading to rework and delays.
- Delays. If one function is delayed in completing its work, it can cause delays for the entire development process.
- Quality issues. If the work handed over is of poor quality, it can cause delays and rework.
- Loss of context. When work is handed over from one function to another, context can be lost, leading to misunderstandings and errors.
There are several ways to reduce handovers within cross-functional teams:
- Keep teams small. Smaller teams are more efficient and can reduce handovers. By keeping teams small, each member can contribute more, and there is less need for handovers.
- Everyone picks up tasks. Cross-functional team members should be able to work on any task within their area of expertise. This allows for a more flexible and efficient workflow, reducing the need for handovers.
- Share knowledge. Sharing knowledge and expertise within a team is essential to reducing handovers. When team members are knowledgeable in each other’s areas of expertise, they can work more collaboratively, reducing the need for handovers.
- Early involvement. Involving all team members in the development process from the beginning can help to reduce the need for handovers. This ensures that all team members have a clear understanding of the project goals and requirements and can provide input throughout the development process.
- Ownership. Facilitating a feeling of ownership among team members can also help to reduce handovers later in the game. When team members take ownership of their work, they are more likely to see it through to completion, reducing the need for handovers.
- Empowerment. Empowering team members to make decisions and run with a task without needing a “yes” from others can also help to reduce handovers. When team members have the authority to make decisions and take action within their area of expertise, they can work more independently, reducing the need for handovers.
Calculating Cycle Time
There are a few different ways to look at the concept of cycle time, depending on how your team defines it. Here are three common ways:
Total cycle time
This formula calculates the total time it takes for a single unit of work to move through the entire development process, from ideation to deployment. To calculate total cycle time, you can use this formula:
For example, if you start work on a feature on January 1st at 9:00am, and you deploy it on January 5th at 3:00pm, the total cycle time would be:
Total cycle time = January 5th at 3:00pm - January 1st at 9:00am = 4 days, 6 hours
Work item cycle time
This formula calculates the time it takes for a single unit of work to move through a specific stage of the development process, such as coding or testing. To calculate work item cycle time, you can use this formula:
For example, if you start coding work on a feature on January 1st at 9:00am, and you complete it on January 2nd at 12:00pm, the work item cycle time for the coding stage would be:
Work item cycle time (coding) = January 2nd at 12:00pm - January 1st at 9:00am = 1 day, 3 hours
Process cycle time
This formula calculates the time it takes for a single unit of work to move through a specific set of stages in the development process, such as coding, testing, and deployment. To calculate process cycle time, you can use this formula:
For example, if you start work on a feature on January 1st at 9:00am, and you complete testing and deployment on January 4th at 6:00pm, the process cycle time for the testing and deployment stages would be:
Process cycle time (testing and deployment) = January 4th at 6:00pm - January 1st at 9:00am = 2 days, 9 hours
The impact of Cycle Time on business outcomes
The impact of cycle time on revenue is significant. By reducing cycle time, software development teams can deliver high-quality products more quickly, allowing businesses to generate revenue sooner. This is especially important in fast-paced industries where time-to-market is critical. By delivering products faster, businesses can gain a competitive advantage over their competitors and increase their revenue potential.
Customer satisfaction is another important business outcome that is impacted by cycle time. By delivering products faster, teams can respond more quickly to customer needs and feedback, resulting in more satisfied customers. This can lead to increased customer loyalty, positive word-of-mouth, and ultimately, increased revenue.
Time-to-market is also a critical factor in business success. By reducing cycle time, teams can respond more quickly to changing market conditions, such as shifting consumer demands or emerging industry trends. This can give businesses a significant advantage over their competitors, allowing them to bring products to market faster and capitalize on emerging opportunities.
By improving efficiency and productivity, teams can reduce stress and burnout, leading to a more positive work environment and increased job satisfaction.
Why focus on reducing Cycle Time?
Reducing cycle time can have a number of benefits for businesses, including increased efficiency, improved customer satisfaction, cost savings, staying competitive in the market, and improving a company’s overall profitability.
Some of the key benefits include:
- Faster time-to-market. By reducing cycle time, teams can deliver products to market faster. This can give the organization a competitive advantage, as they can respond more quickly to changing market conditions and customer needs.
- Improved quality. When teams work more efficiently, they can spend more time on testing and quality assurance. This can result in higher quality products and a better customer experience.
- Increased productivity. By reducing cycle time, teams can complete tasks more quickly and take on more work. This can lead to increased productivity, as the team can accomplish more with the same resources.
- Lower costs. When cycle time is reduced, teams can operate more efficiently, which can lead to cost savings. For example, by reducing the time it takes to complete a task, the team can reduce the number of hours worked and the associated labor costs.
- Improved employee morale. When teams are able to work more efficiently and accomplish more, it can lead to increased job satisfaction and improved employee morale.
- Better customer satisfaction. By delivering products faster and with higher quality, teams can improve customer satisfaction. This can lead to increased customer loyalty, positive word-of-mouth, and ultimately, increased revenue.
- Enhanced agility. When teams can work more efficiently, they are better equipped to respond to changing market conditions and customer needs. This can give the organization an enhanced agility and ability to pivot when necessary.
Cycle Time is akin to the speedometer of engineering. Monitoring and enhancing Cycle Time can help you innovate, outpace the competition, and retain great talent. Cycle Time has broader implications that extend beyond engineering; it also serves as a vital indicator of business success.
Despite practicing lean and agile development, numerous engineering organizations seem content with their process being proof enough that they care about speed and are operating expeditiously. However, these teams may not be tracking any type of speed or, worse yet, may be relying on metrics that could result in dysfunction rather than speed.
Mary and Tom Poppendieck, who popularized the idea of incorporating lean manufacturing principles into software engineering, explore this phenomenon, particularly for Cycle Time, in their book Lean Software:
“Software development managers tend to overlook Cycle Time, perhaps because they believe they are already operating as fast as possible. In actuality, decreasing batch sizes and addressing capacity bottlenecks can significantly reduce Cycle Time, even in organizations that consider themselves efficient.”
- Mary and Tom Poppendieck
In essence, instead of relying solely on intuition that you are operating at maximum velocity, why not augment your understanding with quantitative measures? As with other metrics, tracking Cycle Time can decrease bias and provide a reliable baseline to enhance improvement.
How does cycle time relate to other process measurements?
In manufacturing and software development, there are several related process measurements that are used to measure process efficiency and effectiveness. Some of the key related process measurements to cycle time include:
- Lead time. Lead time is the time it takes to complete a process from the moment a customer places an order until the finished product is delivered. It includes both processing time and waiting time. Cycle time is a subset of lead time that only measures the processing time. Lead time provides a more customer-centric view of the process and is influenced by cycle time.
- Takt time. Takt time is the pace at which products need to be produced to meet customer demand. It is calculated by dividing the available production time by the customer demand. Takt time is often used as a benchmark for production planning and scheduling. It can be used in conjunction with cycle time and other process measurements to ensure that production is optimized to meet customer demand.
- Throughput. Throughput is the rate at which a system can produce finished products. It is typically measured in units per hour or units per day. Throughput is influenced by cycle time, as shorter cycle times can increase the rate of production and improve throughput.
- Work in progress (WIP). WIP refers to the number of items that are currently being worked on in a process. It includes items that are being actively processed as well as items that are waiting to be processed. Reducing WIP can help to improve cycle time and lead time, as it reduces the amount of waiting time in the process.
- Defect rate. Defect rate measures the number of defects or errors in a process. By reducing the defect rate, teams can improve cycle time and lead time, as they can spend less time on rework and correction.
These are all interconnected and can be used in conjunction with each other to help organizations optimize their production processes.
How does cycle time relate to Cost of Delay?
The Cost of Delay refers to the financial impact of delaying the delivery of a feature or a product. It takes into account factors such as lost revenue, lost opportunity, and increased risk. Essentially, the longer it takes to deliver a feature or product, the higher the cost of delay.
Cycle time, on the other hand, is the time it takes to complete one cycle of a process, from start to finish. In software development, this refers to the time it takes to move a piece of work from the backlog to production.
There is a direct relationship between Cost of Delay and Cycle Time in software development. The longer it takes to complete a cycle, the higher the cost of delay. This is because delays in completing work mean that the business is losing out on potential revenue or other benefits that the feature or product would have provided if it had been delivered earlier.
To mitigate the cost of delay, it’s essential to reduce cycle time by improving the efficiency of the development process. This can be achieved by adopting agile methodologies, implementing automated testing, reducing batch sizes, and optimizing the development pipeline.
By reducing cycle time and minimizing the cost of delay, software development teams can deliver value to the business more quickly and efficiently, helping the organization stay ahead of its competitors in today’s fast-paced business environment.
In their software development process, Amazon tracks cycle time to identify bottlenecks and inefficiencies that slow down feature delivery. By using this data to optimize their development process, Amazon has been able to reduce cycle time and improve their throughput.
By measuring the time it takes for a product to move from the beginning of the production line to the end, Toyota can identify areas of inefficiency and make adjustments to their process.
By tracking the time it takes for a product to move from the warehouse to the store shelves, Walmart can identify areas of improvement and optimize their processes.
The music streaming platform, has implemented a development process known as “Squads” that enables teams to work independently and quickly iterate on features. To measure the effectiveness of their development process, Spotify tracks cycle time for each squad, which has helped them identify opportunities to streamline their development process and reduce the time it takes to deliver features.
Google uses “Site Reliability Engineering” (SRE) to ensure that their systems are reliable and performant. As part of this process, Google tracks cycle time to identify areas where their teams can improve and streamline their workflows. By reducing cycle time, Google has been able to improve the reliability and performance of their systems while maintaining high levels of innovation.
To track their progress and identify opportunities for improvement, Microsoft tracks cycle time for each stage of their development process, from code commit to deployment. By reducing cycle time in each stage, Microsoft has been able to increase their throughput and deliver features to customers more quickly.
- What is the purpose of the cycle time?
- How long is the cycle time?
- What is the expected output of the cycle time?
- What are the potential risks associated with the cycle time?
- What are the potential benefits of the cycle time?
- How will the cycle time be monitored and evaluated?
- What resources are needed to implement the cycle time?
- How will the cycle time be communicated to stakeholders?
- What are the potential impacts of the cycle time on the organization?
- How will the cycle time be adjusted if needed?
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, George Spafford (2013)
- The Time Trap: The Classic Book on Time Management by John D. Adams (1998)
- Time Management for System Administrators by Steven A. Beebe (2005)
- Extreme Productivity: Boost Your Results, Reduce Your Hours by Robert B. Pozen (2012)
- Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value by Teresa Torres (2021)
- Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck (2006)
- Takt Time – Cycle Time by Mark
- Lead time versus Cycle Time – Untangling the confusion by Steven Thomas
- The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban by Andy
- Measuring Process Improvements - Cycle Time by Mishkin Berteig
Want to learn more?
Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.
No spam! Unsubscribe with a single click at any time.
Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.Join our community
Made with in Copenhagen, Denmark
Want to learn more about about good product development, then browse our product playbooks.