Estimating in Kanban is a hot topic. Many people ask us how to estimate projects in Kanban. Well, you don’t. Learn how in this post.
It is curious how in era of the Big Data, Machine Learning and AI many organizations still apply practices of clairvoyants and shamans in trying to predict the future. They claim “We use big data to understand customer behaviors” and I say “Yes, and you ask your development teams for estimates. How cool is that :)”.
In Kanban we use a simple yet powerful alternative to estimates based on data and statistics.
The Myth of Estimates
Making predictions does not increase predictability. No matter how many times we estimate how long it will take to do something, that does not affect the capability of the system. Predictability is a property of the system and if we don’t understand our system we cannot predict its behavior.
A Little Science
It is one thing to estimate what a single person will take to do something, and another very different is to estimate the time it will take a User Story to go from the Commitment Point to the Delivery Point.
When someone asks “When will it be done?” What they really mean is “when will it be in production?”. Nobody has a clue. People is either lying or guessing, or both.
There are several reasons why estimating is a waste of time and dangerous for your business, because you are taking decisions based on wrong data. You can investigate further by yourself:
- Information Theory: “The Cone of Uncertainty” – at the time of making the estimate we have very little information and it will only get better as the project moves on. That’s the reason we recommend iterative and incremental development and funding of projects.
- Mathematics: “Covariance” – in a linear dependency of two or more variables, the fluctuation of other variables down is determined by the maximum deviation established by any of the preceding variables.
- Queuing Theory: Lead time increases when resource utilization is high in a system with variation.
- Lean: “Flow Efficiency” – Low flow efficiency typical of most organizations means that most of Lead Time is influenced by environmental factors. As a result, Lead Time is not very sensitive to the size or complexity of a single feature, or to the specific people involved or their skills.
Product development approaches
Traditional project management makes a promise based on the triple constraint of scope, schedule, and budget. After an estimation and planning, a budget is set aside and a scope and schedule are agreed upon.
Agile does not make such commitment. There may be an agreed upon delivery date some time in the future but scope is flexible. Some high level definition of scope may be in place, but fine details evolve over time.
Kanban does not seek to make a promise and commit based on something that is uncertain. A typical Kanban implementation involves agreement that there will be regular delivery of high-quality working software.
Kanban offers a commitment to a level of service for each class of service, and a commitment to reliable regular delivery, transparency, flexibility on prioritization and processing, and continuous improvement on quality, throughput, frequency of delivery, and lead time.
How does estimating in Kanban work?
It doesn’t really. We don’t estimate in Kanban, we use probabilistic forecasting. But, in order to do that we need to properly design and utilize a Kanban System.
Design your Kanban System
In order to create a predictable system you need to be clear on the arrival point and departure point of your system. Within these boundaries is where the magic happens.
You need to adopt the six key Kanban practices which will allow your delivery system to become predictable over time. You can use our Kanban Maturity Assessment to understand how well you are adopting Kanban.
In Kanban we can improve predictability by reducing sources of variability in our system. We use Cumulative Flow Diagram, Lead Time Histogram and Lead Time Scatterplot (or Run Chart) in order to understand how well our system is performing and detect areas for improvement.
Variability is a necessary evil. In order to innovate we need variability but not to the point that our process is completely unpredictable.
We want to allow certain level of variability in the Fuzzy Front End but not so much in the development process. You surely don’t want to have an unreliable deployment process, frequent production bugs, uneven User Story sizes, a Bus Factor of 1, too many dependencies with other teams, queues all over the place or manual regression testing.
Typical sources of variability in development processes are:
- Work Item Size
- Work Item Type Mix
- Class-of-Service Mix
- Irregular Flow
- Batch Size
- Requirements Ambiguity
- Expedite Requests
- Irregular Flow
- Environment Availability
- Other Market Factors
- Difficulty Scheduling Coordination Activities
Estimating in Kanban = Forecasting
Estimating in Kanban is not about guessing, guesstimates or using a crystal ball. We use probabilistic forecasting and statistics.
Depending on the context, after 2-3 weeks of running Kanban you will be able to start forecasting single work items as well as full projects.
Let’s see how we do this in Kanban adoptions.
Single Feature Forecasting
The problem I see in most companies I work with is that due to a lack of understanding of the capability of their development process they just keep pushing stuff into the development pipeline hoping it will get done eventually. What they don’t realize is that by doing this they become slower, people gets stressed and technical debt accumulates.
Unless you put some data on the table based on a predictable system you cannot end this vicious circle of business asking for estimates, development teams lying and business pushing a lot of stuff so that something gets eventually done, which creates a more slower and unpredictable system which in turn causes business guys to push more stuff.
Once you have been properly using Kanban for 2 or 3 weeks you will be able to get a Lead Time Histogram. This is the tool we will use to provide an accurate forecast.
We typically use 85% percentile to make scheduling decisions.
If we start too early, we sacrifice the opportunity to do something else that may provide value. If we start too late we risk incurring the cost of delay.
If we pull the feature into our Kanban system on April 1 we have 85% probability of on-time delivery. On January 1 the item becomes available for selection at Kanban system replenishment. The ideal time to start is April 1st. After May 10 our option to deliver this item expires and we would discard it from our pool.
So, these are the wise questions you should be asking yourself:
- Should we start this item now or can we wait and do something else instead?
- Is it too late already to start this item?
- What is the amount of risk we can assume with this item? 85%, 90%, 95% or should we start as soon as possible sacrificing other options?
- What is the weekly cost of delay of this item?
Multiple Features (Project) Forecasting
In his website Focused Objective, Troy Magennis has many great tools for monitoring and predicting software development. This site is a well of wisdom and contains many great resources for free.
This tool allows you to forecast how long a single feature or project will take using Agile or Kanban and Montecarlo Simulation. It calculates probabilities based on your historical data.
I know what you are thinking, “what happens when the team or product is new and there is no historical data?”. Well, it’s easy. For instance, you can do the following:
- You can start by breaking down your scope into all the work to be done, using a tool such as User Story Mapping
- Determine based on your experience, wisdom or past similar project a range of uncertainty in throughput. How many stories would you say your team can do per week. Define a minimum and a maximum
- Input that data into a Montecarlo simulation tool and you have your best guess
- Iterate and update