A deep-dive into iteration planning and predicting how long something will take
It’s no secret that developers are atrocious at estimating how long a task will take.
It doesn’t matter what your company calls them: stories, tickets, tasks, epics, sub-epics. Estimating the amount of time to allocate to a development chore is difficult… Really difficult.
In 2015, Standish Group found that only 29% of projects were completed on time given contemporary agile development practices. By extrapolation, one could make the assumption that roughly 29% of tasks are estimated correctly.
That’s because, if every story was estimated accurately, 100% of projects would’ve been completed by the due date.
This is not a perfect assumption though. A team could accurately estimate 99% of all tasks under a project and still miss the due date by months. In my opinion, this is the more likely scenario.
Many projects have been blocked by one dreadful task that takes five times, ten times, or 20 times the initial estimation.
This is what’s commonly referred to as “the blowup factor” and it’s baffled developers for decades.
Why Is Task Estimation So Hard: The Blowup Factor
I found this tweet by Erik Bernhardsson that I love — I truly believe it encapsulates the entire issue in 280 characters:
Imagine we are a development team responsible for maintaining a grocery store API. We need to create a new endpoint that allows customers to buy cereal.
Examining our past sprints, we notice that we created an API endpoint that allowed our customers to buy soup — this took a day of development time. We also found one endpoint that allows our customers to buy chips — this took two days of development time.
Lastly, we found one that allowed our users to buy dairy products — this took three days of development time.
At face value, all three of these endpoints are comparable to the new endpoint we need to build. How would you estimate how long this new task would take?
Most developers would lean towards the middle option and say two days. Some teams are pessimistic and may opt to score the worst case: three days.
But there’s always a dark house chance this task will take a wrong turn. Perhaps the newest developer gets stuck on this story and runs into many snafus that senior developers would avoid.
Perhaps the “buy-cereal endpoint” that we must create has an unexpected dependency that soup, chips, and dairy didn’t.
Let’s just say, hypothetically, there’s an unprecedented chance that this task takes 28 days of development time.
I understand this example is a little hyperbolic. But bear with me as I’m attempting to highlight the issue in layman’s terms.
If we have an array of all the “buckets” of how many development days this story could consume, the array would look like this: [1, 2, 3, 28].
So, many developers would score this story at two or three days of development time — which is still consistent with the median. The median amount of days this story would take to complete is still two and a half!
The problem is that the average amount of time this story would take is actually (1 + 2 + 3 + 28) / 4 = 8.5 days of development time! A stark difference from the median.
This is the whole point Erik is getting at: the blowup factor is inevitable. Even straightforward tasks like this will eventually succumb to an unprecedented “blow up” and require much more development time than we planned on.
Summary
Projects miss their due date when one task takes ~10x the estimated development time. This is called “the blowup factor.”Most developers estimate tasks based on the median, not by the average.The median does not take into account the blowup factor, but the average does.
So, now that we understand the blowup factor, can we better estimate tasks?
No. No, we can’t.
Task Estimation: It’s a Lost Cause
Photo by David Kovalenko on Unsplash
“The blow-up factor” is truly unimaginable… until it happens.
In my career as a full-stack developer, it’s the simplest-looking stories that end up throwing the biggest monkey wrench into the system. Humans can’t estimate based on an unimaginable monster. We’re not programmed to do it.
Even if we could, would it really help us?
Imagine if we were perfect in estimating the average of the four grocery store endpoints: 8.5 development days for each story.
Three of those API endpoints would’ve been completed ahead of schedule and one of them would still be long overdue. This doesn’t help developers, or project managers, plan in the slightest.
Lastly, just how big is the blow-up factor?
We know that stories often do blow up. But what’s the additional development time of a blow-up? Is it five times? Ten times? A hundred times? The truth is, we just don’t know and it’s different for every story.
To summarize
Humans can’t estimate the unpredictable. Thus, we can’t take into account blow-ups.
Even if we could, individual stories would often be mislabeled — either completed much earlier or much later than intended.
It’s hard to nail down the true cost of a blow-up. Blow-ups could be an extra day of development time or could be extra months. It’s difficult to account for in estimation planning.
That said, we can be better prepared for task planning sessions!
By taking a step back and re-evaluating our goals as to why we are estimating tasks in the first place, we will be able to combat the blow-up factor, and put our product managers in a position to succeed!
Taking a Step Back: What Do We Want to Achieve With Task Estimation?
As a developer, you’re doomed to being a bad estimator.
But what separates good developers from great developers is being able to do three things: break up stories into more manageable chunks, deliver key performance indicators to business entities, and communicate when a story has “blown up.”
Let’s break this down.
Compartmentalizing stories
Most teams estimate stories as a means to understand if a task is too big. Breaking up stories into more manageable chunks is key to continuous delivery, agile development, and productivity.
Don’t worry so much about nailing down exactly how much time a story will take. Instead, develop a good eye for when a story needs to be broken down into multiple smaller stories.
I promise you, developers who are able to break down stories and define them well are celebrated by their peers and managers.
Teams like small, measurable, and defined. Not monolithic, ominous, and ambiguous.
At Ford Motor Company, my team does something awesome that I highly recommend you try!
Rather than estimate tasks based on time, we estimate tasks based on complexity. We score every task on a 1 to 8 scale, 1 being not complex, and 8 being tremendously complex.
This does two things for us:
It is an admission that we will often estimate the time a story is completed incorrectly — thus, we don’t try.It allows us to ask the question: “Would you be scared to pick up this story?” Because that’s the real litmus test for when we need to break it up. If a story is too complex, developers are going to be hesitant to pick it up, unhappy while working on it, and need to rope in more unplanned help from other resources.
Delivering KPIs and showing progress
Often, we estimate stories so that businesspeople can have an indicator that developers are making effective progress.
If that’s the case, we need to be really smart about how we decide our KPIs. Looking at the raw number of “points” we accomplished in a sprint can be fun but is often inaccurate.
I’ve noticed “big point” stories often can be quite simple and “small point” stories take less time but perhaps more energy.
Often, businesspeople impose bogus KPIs such as “lines of code written” or “time spent at computer.” These KPIs create perverse incentives for developers to add more code than needed, or complete tasks in a more round-about way in order to meet goals.
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery
I wouldn’t provide KPIs based upon developer estimation. I would instead design KPIs around feature delivery, product performance, and developer teamwork.
The golden rule: Communicate blowups
If you don’t take away anything else from this article, learn this one phrase: Avoiding catastrophe is all about communication.
It may feel like your pestering your project manager every time a story blows up. It can be embarrassing — especially as a new developer — to admit a task is going to take longer than estimated.
But it’s imperative to reach out and get help when needed. At least give managers warning to adapt their plan around you.
I have never in my life heard a project manager tell me: “Max, you’re talking to me too much.”
It’s always something along the lines of: “I’m blind without you guys telling me how tasks are going.” “Talk to me more,” or “I need more insight.”
Task estimation is good at giving you a litmus test for when a task has “blown up.”
If you’re speeding past the delivery date, don’t spend much more time spinning your wheels on your own. Reach out, and get the help you need to put a lid on the blow-up.
TL;DR
Keep estimating based on the median. Don’t try to plan for the unexpected.Break stories down.
Set smart goals (goals set by task estimation are not smart).
Don’t be frustrated when tasks take much longer than initially estimated.
Make sure that when a task has blown up, you communicate the issue to your team and managers.
What are your tips for estimation planning? How do you “put a lid” on blow-ups?
Previously published at https://medium.com/better-programming/a-junior-developer-explains-task-estimation-cf4b16b70f6b