Cycle time vs velocity: which metric is better?

Software teams sometimes utilize cycle time and velocity as two standard metrics to measure their progress and efficiency. These metrics help the teams predict how long it will take them to finish a piece of work. Both metrics are helpful, but we’ll elaborate on their differences in this article and explain why we firmly believe cycle time is superior.  

What is cycle time in Agile software development?

Cycle time is a performance indicator that shows how long a team needs to work on a specific task from start to end. You can track it by measuring the time required for a task to move from the “In Progress” to the “Done” status in a Jira board or other team management tool. 

Cycle time considers the time needed to perform each task and the amount of work produced. Thus, it’s an essential indicator for assessing the effectiveness of the software development process. Additionally, it can assist your team in locating areas of improvement and bottlenecks, thus resulting in quicker and more effective development cycles.

How is velocity defined in Agile teams?

The metric called velocity, typically expressed in weeks or sprints, determines how much work your team can finish in a specific amount of time. You can calculate it by summarizing the number of story points your team finishes in a sprint. Story points consider complexity, risk, and uncertainty to estimate the work needed to complete a feature or user story.

Average velocity is a valuable metric for capacity planning, i.e. how much work your team can complete in future sprints. However, since velocity doesn't measure the quality of work produced or the time required to do specific tasks, it shouldn't be the only indicator of a team's performance or productivity.

How is cycle time related to software metrics?

Now that we have explained what cycle time is, let's see how it can be positively impacted by improving other key software process metrics:

Work in progress (WIP)

WIP denotes the number of working items currently in progress. It comprises both actively processed items and items in the queue for processing. Reducing WIP improves cycle time and lead time, as it reduces the waiting time in the process.

Lead time

Lead time is the duration from when a customer places an order to the delivery of the final product. It includes both processing time and waiting time. Cycle time is a subset of lead time that only measures processing time. Lead time provides a more customer-oriented view of the process and is impacted by cycle time.

Takt time

Takt time is the pace at which products must be produced to meet customer demand. It is calculated by dividing the available production time by the customer demand. Takt time is used with cycle time and other process metrics to ensure production is optimized to meet customer demand.

Throughput

Throughput is the rate at which a system can produce finished items. It is typically measured in units per hour or units per day. Throughput depends on the cycle time; a shorter cycle time increases the production rate and improves throughput. Velocity is a throughput, but instead of a total of story points, it's the total of work items.

Defect rate

The 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 by spending less time correcting and redoing.

How is velocity used to track team performance?

The sprint is a period that typically lasts one to four weeks. A metric called velocity indicates how many story points, or units of work, your team can do in that time. The team sets story points for each user story or feature based on complexity, size, and uncertainty. You can calculate the team’s velocity by summarizing the story points of all the user stories your team completed and accepted in a sprint. For example, if your team finished 15 user stories with 60 story points in a two-week sprint, your velocity would be 30 story points per week.

Velocity tracking could support your Agile software development project management and planning. First, it can assist you in determining how long it will take to finish your project or release by dividing the total number of story points in the backlog by your average velocity. For example, if your backlog has 300 story points and your average velocity is 30 story points per week, you can expect to finish your project in 10 weeks. 

Second, it enables you to monitor your team's performance and progress by comparing your actual velocity with your expected or planned velocity. Suppose your planned velocity is 25 story points per week, but you achieved a velocity of 15 story points in the week. In that case, you should identify and address the factors slowing down your team: scope creep, technical debt, or communication issues. 

Third, velocity helps you improve your team's productivity and quality by using weekly reviews and retrospectives to learn from your successes and failures and adjust your processes and practices accordingly.

Why is cycle time a better metric than velocity?

There are several weaknesses in estimating development velocity:

Subjectivity and inconsistency

Velocity is measured by story points developed in a sprint, a relative measure. Associating story points with time is one of the scariest yet most widely used estimation methods. Developers are requested to estimate the time needed to complete a task. Therefore, one story point could represent a day or 4 hours. The main drawback is that different teams need different times to complete a task.

Misinterpretation by stakeholders

Poor definition of story points (volume of work) can lead to wrong expectations of the stakeholders. Usually, Stakeholders want a delivery of client value (and not story points).

Potential for gaming the system

Velocity can cause the team to focus on delivering features rather than solving problems (delivering value) for the end user.

Variability and fluctuations

Velocity estimates how much work a development team can complete based on previous time frames of similar work. This number is relative, and each team can have a different velocity. It’s all about context!

Overemphasis on quantitative metrics

Focusing on quantitive metrics - the team will skip code reviews and unit tests (the quality). That will accumulate technical debt, which is entirely unacceptable.

What are other benefits of the cycle time over velocity?

Process improvement

Cycle time uncovers areas where the process could be more efficient. Long cycle times indicate bottlenecks and idle activities that software development teams must eliminate to increase workflow effectiveness. If you are using cycle time for planning, the goal is that all the planned units of work (i.e. user stories) are approximately the same size. With this habit, your team can split work into equally sized portions. It helps you better estimate how many issues of different kinds (bugs, tasks, stories) you can complete in a sprint.

Precision and predictability

Measuring cycle times can help in achieving the predictability of software processes. Predictable processes are easy to control, leading to reliable and up-to-date project predictions based on accurate data. Discussing outliers and understanding why a specific task takes longer than expected enhances the team's ability to plan and estimate work. In other terms, if you can’t identify and resolve the outliers, it will be hard to create a good plan as a team.

Universality and clarity

To measure cycle time, you don’t need extra meetings or rituals; all you need is the right tool, such as Axify. By introducing cycle time to your planning process, your team will spend more time partitioning and defining tasks better, contributing to more efficient solution development.

Efficiency over output

Cycle time is a proper metric for measuring a process's performance. By knowing how long it takes on average to complete a cycle, teams can establish standards and benchmarks for performance. Due to its strong impact on business outcomes and objectivity, cycle time is an excellent metric for continuously improving your software team’s ability to iterate quickly.

Adaptability across different work

Although cycle time is a more objective metric than story points, some think development teams can reduce it by lowering the scope of work completed in a given cycle, which is valid to a certain extent. This type of optimization will benefit your process. Indeed, many teams work with large issues, and splitting the work into smaller chunks helps iterate faster.

This is especially valid for smaller pieces of work, such as deployments. Reducing cycle time requires you to complete work faster, so your team must identify and fix actual process bottlenecks to improve.

How does cycle time impact business outcomes?

Here are ways the cycle time can positively impact business outcomes.

Speed to market

Time to market is an essential factor for business success. By decreasing cycle time, teams can react faster to dynamic market conditions, such as changing consumer needs or new industry trends. This will give companies a significant advantage over the competition, allowing them to bring products to market faster and capitalize on emerging opportunities.

Customer satisfaction

Cycle time also impacts the other business outcome - customer satisfaction. By deploying products faster, teams will intercept customer needs and feedback, resulting in greater customer satisfaction. This will increase customer loyalty, a positive reputation, and revenue. 

Predictability

The team will be better equipped to respond to changing market conditions, and customer needs if the process is more efficient. This will give the company greater agility and the ability to balance when necessary. By increasing productivity and efficiency, teams will reduce stress and burnout, improving the work environment and fostering job satisfaction. The more the team becomes predictable, the less estimation they will use.

Resource optimization

Despite practicing Lean and Agile principles, many software teams are still concerned that their processes' speed is not as expected. Therefore, these teams should start tracking some type of speed (e.g., cycle time), which will advise them on optimizing their teams’ size, habits, and other resources. 

Bottom line

Manual metrics calculation can provide valuable insights, but an automated tool like Axify can prognostically model system behaviour and track software development effortlessly. Axify is a single platform for observing all the key performance indicators that will help you improve your development and delivery processes, including cycle time. Axify also has the metric of throughput, which can be used instead of a story point velocity.

It provides high-quality dashboards and constant tracking of multiple metrics in real time, simplifying the whole process and enabling teams to concentrate on improving. Thanks to our experience with functional dashboards, the stability of your processes will improve, helping to streamline operations and increase team satisfaction in a win-win situation. Feel free to contact us for a quick demo on improving your software development process.