Forecasting with Takt Time

Ajay Reddy

• 12 August 2014

• game-help

• forecasting predictability

Forecasting with Takt Time

Software development is filled with risk and variability. Its elevated level of uncertainty and risk make it challenging to develop accurate forecasts. Poor forecasting, in turn, erodes trust and any sense of predictability with an organization’s non-technical leadership. These values are are essential to creating sustained agility and high-performance within any organization, so tools that enable us to do a better job here are critical to long-term success.

Scrumban allows teams and organizations to apply more advanced modeling techniques when there’s a need for greater precision or when there’s a need to isolate and measure the impact of specific risk factors in a much more granular fashion.

Modeling reality through repetitive simulations lets us produce the rough equivalent of actual performance data (assuming our models are an accurate reflection of reality). Past performance may not be a guarantee of future results (there are always going to be outliers), but it does improve our understanding of the probability of various outcomes that would otherwise remain elusive.

The first evolutionary improvement we can make to Scrumban’s additional forecasting techniques lies with how we apply Little’s Law. It is fairly typical to start working with Little’s Law by using average values associated with throughput, WIP and lead times. In forecasting things like project lead time, however, as Dimitar Bakardzhiev notes, it’s best to use Takt Time measurements (the time between two successive deliveries) in our calculations:

We favor using Takt Time over Lead Time for a number of reasons. First, most software development work is done in parallel (meaning team members are working on a number of things simultaneously). Using average Lead Time can lead to inconsistent results. It essentially replicates a scenario where all items are delivered one at a time at a regular cadence. We know reality is far different. Takt Time, on the other hand, implicitly accounts for this variability.

Assume 3 user stories are pulled into the work queue on the same day. The 1st user story is delivered on the 3rd day, then the two remaining items are delivered on the on the 6th day. The 1st and 2nd items would have measured Takt Times of 3 days. The 1st item’s Takt Time is measured from the date work began (because there’s no prior delivery to measure against). The 2nd item’s Takt Time is measured from the date the 1st item was delivered. The 3rd item, however, has a measured Takt Time of 0 days. This is because it was delivered on the same day as the 2nd item. Because Takt Time accounts for both Lead Time and WIP, it maintains the necessary relationships for Little’s Law to apply while accounting for parallel deliveries.