This incident happened in November 2019 around Diwali time in Chennai. A close friend of mine travelled from Bangalore to Chennai on an official visit and wanted to meet me before his return to Bangalore the same day.

We worked on a plan and somehow met at a common place with just a few hours left to reach Chennai Central for boarding his train.

Given the tight schedule, we could hardly speak in a relaxed mode nevertheless we had a lot to exchange. We had everything to discuss over a cup of tea standing near a tea shop.

With no good ambience to continue our conversation, my friend suggested why not we both get into the cab and continue speaking while ensuring his travel plan is intact.

After some time, he requested the driver suddenly to stop the cab in the busy market roads of Thyagaraya Nagar (otherwise called Mambalam) en route to Chennai Central.

He wanted to surprise his mother in law with a Kanchipuram silk saree on her 70th birthday coming soon. The idea was definitely a noble one nevertheless there was not much time left.

He somehow persuaded me with a forecast to get a saree in less than 15 minutes and get out from a busy shopping mall nearby. With not even a week’s time for Diwali expecting a huge last-minute shopping by many, I wasn’t convinced for him to own such a risk.

But what is bound to happen, had to happen. He selected a wonderful silk saree in less than 10 minutes and stood in a long queue for about an hour to get it billed.

Finding that he was running short of time and can’t get his billing done, had no choice other than to give up the plan of buying a saree. He left with a heavy heart back to the cab to board the train on time to reach home safe.

While coming back to the local suburban train all alone, I had a realization with all the series of activities that happened in the last couple of hours. I found it neatly ties back to estimating work in a complex domain and the reason why it fails.

My Realization: # 1 Reason why your estimates might go wrong

Forecasting is focused on figuring out a target END date. I don’t find anything wrong with that. But you never track the START date for the same work. Start dates need to be triggered by the delivery of prior work.

Your start dates are mostly tagged to nice even calendar dates and Sprint boundaries. Often to the first day of the Sprint or a month or a quarter. This, of course, ignores that the team may not nicely complete the prior commitments by the day before that date.

The prior or existing commitments absorb the time and attention from the Developers. An easy warning sign is to see how many dedicated individuals (as Developers) we have on the team when the new work starts. More often than not, the Developers are called upon to help in existing production issues, scheduled migration activities, on-going training, etc.

The Developers’ commitment to start the work doesn’t have to guarantee that their associated dependencies too ‘Start’ ahead of/on that same timeframe. One Scrum team available in the delivery chain isn’t good enough. Often you end up seeing work getting blocked sooner due to a dependency elsewhere. Ensure all the dependencies need to be ready to accept and complete work as planned.

From my limited experience of what I have seen, the number one inhibitor for starting on-time is missing/inadequate Developers for the new forecasted work. The root cause of this is not effectively managing the skill and availability of Developers to match the upcoming work/work intake. Training is critical in the upskilling of Developers because the individuals were skilled for the prior work and not necessarily ‘ready’ for the upcoming work forecasted.

Quick Tips to prevent falling into this trap:

1. While estimating, brainstorm, and list all reasons that might inhibit starting the work right away, if required to. This good list of excuses is the aspects you need to pay attention to before starting to work as per the plan later.
2. Visualize the utilization patterns and see how that can anchor the Developers transitioning from the existing piece of work to the work forecasted.

Are we effectively efficient or efficiently effective? Your answer to this question at this juncture gives a good indication and confidence on how to tackle the road ahead.

Wrap up!

I hope you still remember my friends’ challenge that I narrated at the beginning. He forecasted for 10 minutes and in fact, he wasn’t much deviating from the actuals in selecting a saree.

But when all the work starts to happen, his forecast failed given the dependencies (long queue) and utilization challenges ahead (less billing counters).

Remember, you need to get better at tracking the ‘Start’ date and worry less about forecasting the ‘End’ date.