A cycle time formula helps software project managers and engineers reach a reasonable estimate for the duration it takes from the start to finish of a project. Software teams always have one project or more underway. Without generalizing too much, projects are how things get done and how developers can focus on their work.
When you take a step back, it’s easy to appreciate that projects are just a series of tasks. We often lay tasks end to end to achieve project objectives. These objectives can be entirely new products or just a few touch-ups to existing systems. Almost always, and in line with the CI/CD mantra, these tasks include deploying new features continuously.
This post explores the use of cycle time formulas to keep software engineers productive, not overwhelmed by overly ambitious cycle time estimates. The general assumption is that you’re fully aware of cycle times. However, we’ll start with a quick recap as we build out the logic behind the formulas discussed later.
An Explanation of Cycle Time
Cycle time is the measure of how long a unit task lasts. A task’s cycle time can be a few minutes, a few weeks, or even a month. The time unit your company adopts depends on the complexity of the tasks you assign developers. Not so much how hard the tasks are, but the steps and hoops through which developers have to navigate.
Gigantic tasks often exhibit long cycle times because of multiple nodes along the path to completion. There are many strategies you can apply to reduce cycle times. As a best practice, keeping short cycle times has a positive effect on developers’ productivity. The smaller the chunks of tasks you line up, the better chances of completion within time budgets. The opposite would be a monumental task that seems insurmountable to even the most skilled programmers (which also leads to a lot of idle time).
Even when you set reasonable time budgets as cycle times for your project tasks, some moments will leak as idle time. Developers may either have to wait for team members to provide input or need to rest between completing tasks. It helps to account for this time to calculate cycle time accurately.
The final timestamp difference between the start and the finish of tasks represents gross cycle time. The net cycle time, which is the actual productivity time, represents the pure work effort’s duration. This means you must remove idle time. Otherwise, you won’t know how much a particular task costs (in time and effort) and plan accordingly for future task recurrence.
A Simple Formula for Calculating Cycle Time
The simplest formula for cycle time involves the previously discussed net productive time and its determined start and finish times.
The equation above applies to an entire project as much as it holds for just one task. Often, the number of tasks observed (our formula denominator) will be one. This leaves the cycle time equal to the net productive time spent by a project or task actor(s).
Deducing these times is often easy, regardless of the project management tool you use. That’s because every task activity is traceable down to a unit second. In fact, even if you’re using a spreadsheet grid to track projects, timestamps and simple functions should come in handy when calculating cycle time according to the formula above. That said, let’s examine what activities hint at the start and end of a cycle for you to measure cycle times accurately.
Marking the Beginning of a Cycle
The assumption here is that you’re not holding a stopwatch every time a task starts, clicking each time any pauses (idle times) occur. It’s smarter to be on the lookout for specific events and activities during which you measure cycle time. Good cycle starting points mark divisions for activities that matter to your stakeholders. Specific to software development, a cycle time usually starts when a developer commits effort to a task. Also, it’s worth noting that the start of a cycle consequently brings an end to a task’s lead time.
A User Story
User stories help make sense of the work achieved by developers. They answer the question, “would a user be able to do [activity] with the product?” You can measure how much is possible as action items that developers build toward. This is common in test-driven development methodologies. In that case, when you begin work on a user story, that’s an opportune moment to start measuring cycle time.
A Feature Spec
Besides what the user deems important in the final system (user story), you ought to measure from the developer’s perspective as well. For this, you should have a feature specification document. This allows you to create and break down project goals into unit tasks for developers to tackle. This way, each task that moves from “planned” or your backlog list to “active” automatically gets a timestamp for you to start measuring its cycle time. Since we’re measuring time, every feature worked into a system can be that event you start measuring—hence signaling the start of a cycle time interval.
Determining a Cycle’s End
The second timestamp to watch for, yet equally important, is the end to an activity’s cycle. This is an automated tracking process in popular project management tools—as every task sent to a complete pile will have been recorded already. Since tasks move across boards regularly, you should be clear on when a cycle ends. Marking the end of a cycle time means you have accepted the effort and outcomes of a task’s duration.
A Roll to Production
Whether it be a user story or a specification task, it should roll into production at some point. However, there are processes in between (mostly testing) that you should include in the cycle. The inclusion of tests makes sense since every task will undergo the various test types you impose for quality assurance.
Activating a Dark Launch
Launching darkly is a quick way of bringing new features or requested changes to the end user. To be exact, it involves shipping to a small segment of users. All in all, as a launch method, it implies that user stories are complete. The moment you hit the launch button (ship new features) is a great point to stop the cycle time counter.
Once you’ve established the start and finish points for tasks you want to monitor, plug their values into the cycle time equation. Realistically, as long as an event exists as a single entity in your project management system, you should be able to pull its cycle time.
Making Decisions From Cycle Time
All these considerations, and any you’re currently using to determine cycle time, are important only when they aid in decision-making. The first and obvious, use of cycle time after using that formula is setting schedules. If the client, or internal users, ever requests stories or features of the same weight, you should have a general delivery date estimate ready.
The second reason you’ll need cycle times has to do with improving your team’s delivery process. Measuring cycle time can reveal key improvement areas in every developer’s effort process. Not to say you should implement a “big brother” environment (it’s likely to have adverse effects). However, you can (must) address the reasons why developers take a long time on seemingly simple or previously measured cycles. The result is that you’ll consistently improve your software delivery process.
Lastly, cycle times will help you gauge the availability of your software team for new projects. Knowing how long you’ll wait before an ample number of developers are ready for projects reduces the lead time for any new tasks. Such decisions keep the end users/customers satisfied, and more importantly, it maintains good morale among your developer teams.
