You Suck At Estimating
You suck at estimating software. It’s ok, we all do. I know I definitely suck.
The notion that we as software developers can somehow accurately guess at the number of days, hours, points or whatever is fundamentally flawed for reasons we’ll explore in this article.
I often find myself talking with product teams that struggle to deliver accurately, consistently and with high quality. More often than not the knee-jerk reaction from management teams is a natural desire to manage by metrics using concepts like velocity tracking to somehow figure out where the gaps or deficiencies lie within the process. Consequently more often than not in these situations the fingers are pointed at the development team. While in most cases this perception isn’t totally warranted we’ve found that there is a deeper underlying issue that without fail will lead to this outcome. Let’s peel the onion a few layers and look at why this happens.
Software teams have been estimating their work likely since the first software company was founded if not longer. Certainly over the course of my 20+ year career it’s been a regular activity and can be found in all the mainstream software development methodologies such as waterfall, scrum, and even agile(s).
Product and development teams use metrics to estimate for example the number of hours, or an abstraction like story points. In more than a few cases development teams will proudly talk about their use of the Fibonacci sequence to describe relative complexity.
The problem with these systems lies in the fact that they look technical, scientific, and accurate when in most cases they are the opposite. The worst offender, of course, being the Fibonacci method where the perception of science being applied to an unscientific thing leads to an even larger misunderstanding. Our desire to sound like the smartest people in the room, and certainly you’d have to be to understand such an arcane measurement system, has outpaced its usefulness in this area. Regardless, we find that all of these systems are flawed in some fundamental ways. None of them are accurate!
“But Brent” one might say, “It’s true that individual stories may not be estimated accurately, if we do this long enough we’ll have a track record of what the team can deliver and we can use yesterday’s weather to determine what we can produce over a given period”.
It has the smell of truth doesn’t it?
Like X-Files we want to believe and for many years this was my go-to line when selecting an estimation method. That said, over time and with experience I have lost all faith in this approach. It sounds like the old retail adage “We lose money on every transaction but we make it up in volume”. It’s a hollow concept, and I want to grab brent-of-projects-past by the shirt collar and shake him when I think back over all the times I proudly (perhaps smugly) described our Fibonacci estimation values — give me a break.
Why are these systems, any system like this fundamentally flawed from the outset? This is an important question. They are flawed because at the unit level they rely on some developer somewhere looking at a ticket, a story, a trello board, a whiteboard, or whatever tool you use and cautiously sticking their finger in the air and saying “3”. It is a guess and the entire house of cards that estimation builds start with this activity. If you are on a project of any size think of all the time you’ve spent doing exactly this activity. Hold this thought because we’re going to get back to estimation meetings later.
Reason #1
Software development within a team is, at its core level, a human exercise in communication.
Teams that communicate well write better software, more accurately, and with higher quality than teams that don’t communicate well. Period. Full stop.
It is surprisingly difficult to convey a three-dimensional concept in one persons’ mind to others by way of any of the accepted tools we have at our disposal — to serialize it if you will allow me that. Amusingly it reminds me of this scene in Ghostbusters, you may recall.
In this scene Dr. Venkman is testing these subjects for their ESP abilities. When the subject is correct nothing happens — next card, and when they are wrong — an electric shock. Feels a bit like development estimation doesn’t it.
Reason #2
Developers as a species are optimistic about how quickly we can do the work. We often think of this question more abstractly, our brains translating it to “How long will this take in a vacuum” and not “How long will this take given all the other demands of my job and work environment”. These are almost always very different questions with very different answers. When a developer is asked how long a task will take using whatever method you will often get an answer to the former not the latter.
Do your developers help with production? They should. If this is the case, certainly this contributes.
Reason #3
Software development can be competitive. In more than one case a certain gender-neutral machismo, ie “I’m a 10X”, result in underestimated stories on teams that suffer from that character defect within the team.
Reason #4
Business needs can be unclear. It just is; there are mechanisms we can use to realize this and adapt to it.
What do we do about it?
At this point I’ve spent the better part of two pages talking about why we as an industry suck at this activity. There exists an alternative, or at least an alternative until a better method comes along. A different approach that we’ve been using at Tarmac for some time that forgoes the traditional approach to estimation and instead leverages the many advances in modern software development available today.
Below I’ll outline the steps we use to bring the granularity of tickets down, way down, to a simple statement that the developer asks themselves before they start the work.
“Can I finish this today?”
Magical things happen when an organization shifts to this method.
- Every developer delivers something every day at least (on average).
- Granularity of change is small, and therefore safe.
- Product reviews the work constantly meaning that the maximum course correction on a misunderstanding is equally small.
- Conversation and interaction between the team asking for and the team delivering a thing is at a maximum.
- It is almost impossible to have dramatically missed expectations when interacting in this manner.
- Product and the business can do some fuzzy estimation on time to deliver at the # of days granularity simply by looking at the number of tickets in the backlog and assuming 1 day per without large protracted estimation meetings
This is the technique we use:
Step #1
Stop Estimating. Seriously, stop right now. Remember up there ^ when I talked about estimation meetings? What if you could erase those from your calendar and recover that many hours per day/week/month you spend on those. You can.
Step #2
Developers ask themselves before picking up the next story on the top of the backlog. “Can I complete this in a day or less?”. Just that. If the answer is yes, proceed and do the work.
If the answer is no, break the story down into subsequent tasks that can all be completed in a day or less. Link the tickets if you’re super sophisticated or just drag the new ones under the original and proceed.
We’ve found this to be the most magical step. Psychologically if a developer asks themselves abstractly how long something can take they’re off into fuzzy estimation. If that same developer asks, “Can I finish this today”, we find that more developers are more accurate.
Step #3
Leverage CI and then CD to automatically deploy the new granular thing to an environment where product, or the person who asked for said change, can review immediately and provide feedback. We use slack integrations to automatically notify the teams when new work is available for review.
Step #4
If the result is correct move on to the next story. If it isn’t have a quick conversation, adjust the work and make the necessary changes running through the cycle again.
Wrap-up
That’s it. I know it sounds super simple and super basic but we’ve found with a growing number of businesses that there is value in this type of simplicity. Further it deletes or greatly reduces the amount of time wasted on activities that produce inaccurate outcomes as a best-case scenario and focuses on the core activities that drive your business forward.
A final note for those that still aren’t convinced. There exists a more sinister outcome for those teams that adhere to old ceremonies and consistently underperform by the very metrics they provide as a team to their business counterpart, i.e. those folks with the money.
Over time as one missed milestone leads to many the voice of the team becomes smaller and smaller. The metrics used to judge their worth will diminish down to what we term “lagging metrics” meaning there isn’t anything that can be done midstream to fix issues, we can only measure the end result (anyone that does burn up charts will know what I’m talking about). Do this for too long and they won’t be trusted, and then only the electric shocks. You don’t have to take my word for it.
If we can collectively agree that we suck, and in that recognition search for ways to suck less an organization can work to adopt a collaborative and consistent approach like the one I’ve outlined, deliver regularly, incorporate feedback, and communicate efficiently they will find their value and consequently their voice within the organization growing.
Trust often being gained and measured by the following simple concept: Say what you will do, then do what you say.
Thanks for reading!
