Project Management with Kanban - Forecastingoriginally written by David Anderson
Our summary and key takeaways
The biggest question about the efficiency of applying Kanban to your project management is very likely: How are we going to meet deadlines, since the system works on no time estimation and doesn't set time-frames for the iterations?
How to forecast in Kanban?
The answer provided by David Anderson highlights two main sources of this kind of project forecasting. These are: the lead time of the project tasks throughput and the application of the Little's Law. So basically, what we're asked to do is to base our future commitment capabilities on the historical data regarding our team's performance.
This, of course, will prove most successful for teams of a low flow efficiency (the skills, technique nor requirements have not much influence over the lead time in general). But in case of higher workflow efficient teams, we would need to keep an eye on whether the team's performance stays on the same level as in the past, otherwise the predictions may not be accurate.
On top of this, what would be required for this method to work is making sure that we follow the task types and their priority levels, to ensure we apply a correct historical data to a currently estimated task. There also needs to be a decision made about how far back is it best to look (considering that conditions could have changed throughout a time period). As soon as you've gathered the information described above, you can happily apply Little's Law to your estimates: throughput (the rate of delivering) is equal to WIP divided by the lead time.
Tasks homogeneity and keeping up with the types (the Z-curve)
Anderson offers us a useful method of foreseeing the delivery time, basing on a model of 3 coexisting values: the time of preparation and getting the work going (taking up an estimated 20% of the delivery time), the hyper-productive period (60% of the delivery time) and the last phase, composed of the remaining 20% of a lower productivity again.
This system is meant to be working for homogeneous types of tasks. As long as the requirements don't change, the estimates will remain on track. But changing the task's nature (for instance by adding the need to include the stakeholder's input) demands that we apply a modified delivery rate estimate. The point is to make sure that you're applying a correct base data for your estimates.
The benefit of having this type of estimates, sorted by a task class or type, is the ability to match the overall WIP limits to the estimated delivery times. This way we stand a chance of meeting the deadlines within a healthy operating system.
According to Anderson's experience and take on this, applying this method to delivery forecasting is easy and proves reliable, provided that different task types and risk levels are matched correctly with the jobs that we're forecasting for. He also claims this approach to be more effective than the traditional probabilistic way of delivery time estimations, based on researching the times for each task item at the source (developers, product creators), which very often is based on guesswork anyway.