“Ok ok, but when will this be delivered?”
If you have any experience in the peculiar world of software development, I bet you have heard this question several times. Implored.
The question is always made the same way. But it’s the mindset of the asker that dictates what kind of answer she/he expects.
If your enterprise is doing Agile — instead of being Agile — most likely, this question asks for a deterministic estimation.
Deterministic estimation lives in the heart of Gantt charts. Where we can say things like, “we will deliver this project in 7 months and 23 days”. How does this sound in the domain of software development? To me, this sounds like what a fortune teller (equipped with a magic ball) would reply.
Deterministic estimation is wishful thinking. It would be much more comforting to know that we will be done by day X in the future. Sadly, that’s just a comforting delusion.
The software development world exists in the Complex domain within the Cynefin model — this means that we can only infer the relation between cause and effect in hindsight. The recommended approach for managing Complex systems is: probe, sense, respond. Through this approach, new practices will emerge. We don’t have the comfort of having best practices, much less the certainty that we will be done at a certain point in time.
Kanban metrics’ response is based on probabilities — namely, using Monte Carlo simulation over the previous throughput of the team. Therefore it’s a forecast and not an estimation.
For a probabilistic forecast, we use the number of items (therefore rendering the need to estimate their supposed size in Story Points).
By fixing the time (setting a deadline), we can determine the minimum number of items that will be done by that deadline, with a certain confidence degree. That sounds like “we will deliver 43 items or more by the deadline, with a probability of 85%”.
By fixing the scope (amount of work items), we can determine when that scope (or more) will be delivered with a certain confidence degree. That sounds like “we will deliver the full scope (or more) by 16th of June, with a probability of 90%”.
One myth (which I believed for a long time) is that, to use probabilistic forecasting of the number of work items delivered, we need to have items of the same size. This idea comes from the fact that variability is undesired in Lean systems.
But that is not the case. Let’s consider two scenarios: when we haven’t optimized the Value Stream for the work and after that optimization.
In the first case, the time we spend working (touch time) on an item is a small percentage of its lead time. This time can be as low as 2 to 5%, for instance. The waiting times are way longer than the touch time, so its actual size has a small impact.
In the second case, let’s assume that we did a value stream mapping for most of our blockers, and our efficiency is higher. In that situation, it’s the priorities that are the most considerable influence in the lead times.
Be careful, though, to don’t throw the baby together with the baby water — the discussion and clarification around a work item are valuable. They need to happen if we call it a 2 or 5… that we can dispense with.
