“You don’t have sprints, so you don’t know, when the work is done.”
“You don’t have project plan, so you don’t know, when the work is done.”
“You say everything is on the board? How can you know, when the work is done without Gantt chart?”
You don’t need timeboxing, Gannt charts, project plans, yet still you can tell your stakeholders when the work will be completed with certain predictability.
How do we achieve it with Kanban? By:
- data based forecasting supported by metrics
- delayed commitment
- Kanban cadences (with focus on daily meeting, replenishment meetings and delivery planning meetings)
- explicit policies
- and last but not least, following our first Kanban Commandment: stop starting, start finishing
Data based forecasting supported by metrics
We all love to think that our project estimates are based on data and mathematical evidence, but the truth is – very often – that we still use good old gut-feeling.
What is more we tend to underestimate our plans (pretty long sometimes) or be overoptimistic in terms of benefits expected.
Kanban is very radical on that – no estimates! No estimates, only pure, data based forecasting. If you don’t have data, because this is your first appointment – follow the rules of reference class forecasting (1): use the most similar project from the past and treat it as starting point to forecast your results. Then immediately start gathering your own data, adjust and improve.
The metrics that can be used to visualize, measure and improve predictability are lead time or cycle time distribution.
First things first – what’s the difference between the two of them?
- cycle time starts when the work on item begins and ends when the work on item is finalized; (2)
- lead time consists of cycle time and “fuzzy” front end (time between request is made and work on item starts), which is rather customer point of view.
Below an example of cycle time distribution which can be used to illustrate the concept. (3)
90% of items are completed within 18 days.
10% of items are completed in more than 18 days, what means that they can be completed in 19 days or 50 days (or more).
When our stakeholders come and ask, how quickly we can deliver the product, we say that it will be finalized in 18 days with 90% certainty.
Still the remaining red items (10% of total) form a long tail of our cycle time distribution and we should analyse the outliers trying to understand what made them so unpredictable. We should shorten the tail in order to increase predictability and be able to provide a delivery date for requestors.
Additionally if we use backlog prioritization methods like cost of delay, the customers can pick up the next item by themselves and we can quickly tell them, when they can expect it in production – and we know it base on data.
Of course the more data we gather, the deeper we can go with metrics (like Monte Carlo simulation) and forecasting – and better at it. But the most priceless is just to start.
It’s easier to commit even to unrealistic date than keep stakeholders uncertain. Even if we have to move the delivery date, it’s still psychologically safer than saying: “I don’t know.”
If we perceive the workflow as set of knowledge discovery steps, commiting on when we discover the whole knowledge about the process or product becomes irrelevant. Instead Kanban provide a feature we call 2-Phase Commit constisting of: commitment to do work and commitment to deliver.
The first point relates to the moment, when we finished initial discovery process and we commit that the item that crossed the line will be finalized (in this point of time we stop measuring “fuzzy” front-end and start measuring cycle time). We should avoid aborting work after taking this step.
The second point in time which is commitment to delivery is the moment, when we decide and inform the customer about actual delivery/release date.
2-Phases Commit is strongly supported by cycle time distribution and the results of historical data analysis, which we use at “commitment to do work” stage to establish expected item cycle time, within which release date should fall.
There are 7 described Kanban cadences out of which I focus on three, the most supportive for items delivery.
During replenishment meetings team commits to work on certain items from the backlog and that work will not be aborted.
Delivery planning meeting supports the second commitment phase, which is commitment to deliver. Team agrees release date and scope of items for the particular release.
Daily meeting helps in ongoing planning and troubleshooting staying in the closest feedback loop with replenishment and delivery planning.
Make your policies explicit
One of 6 Kanban practices may support your delivery. Policies should make transparent – for you, your team and stakeholders – the rules which drive the work from the moment of receiving the request to the very end (depending what “end” means in your case).
The policies can describe:
- what metrics are used and how do you measure;
- what are your SLAs and SLEs;
- what are your commitment points;
- how you decide when to move an item across the commitment line, etc.
Clear rules help your team to work in a stable pace and give stakeholders the comfort of understanding what is reasoning behind your decisions and actions.
Stop starting, start finishing
When I want to explain people, who have no idea about Kanban, what is this all about, I always start with thic commandment. For me this is Kanban DNA – focusing on finishing work before taking up a new one.
It’s the most true and the most basic and understandable statement – yet the most difficult to accept for a lot of people, which seems to be a bit paradoxical – but this is a theme for a separate article.
Limiting work in progress enhances the predictability by radical shortening item lead time. Removing context switching (have anyone ever used a metric like this?), being variable difficult to measure, and waiting time related to context switching and necessity to maintain huge items inventory are the main keys to understanding, why we should keep focused on limited number of items.
And well, finishing ultimately means that you start to know, when the work is done – just because it’s done.
We, Kanbaners, know how to finish work and how to communicate when work is expected to be delivered, cause we are taught about it from the first day.
Would you like to learn the same?
Join your Kanban adventure!
(2) For more about cycle time calculation, see Daniel Vacanti article: https://leankit.com/blog/2016/12/kanban-calculations-cycle-time/
(3) Illustration by: https://www.digite.com/blog/kanban-cycle-time-analysis/