Over the last year or two I have heard the phrase and idea of “T-Shirt Sized Estimates” come up more and more often in the software engineering/technology world, typically by people that I would think should never be allowed to talk about software estimation. To me it doesn’t seem to be much of a coincidence that people I have known to be horrible at estimation are often the ones who bring this faux estimation process up, and there are some clear reasons why one should never use this type of estimation.
For background, t-shirt sized estimates seem to follow the rule of asking for a small, medium, large, or extra-large estimate against an effort. And, more often than not, the reason why people ask for this type of estimate is because the required information to make good, well-thought out estimates is not available at the time. So, in what passes for a natural response to these people who couldn’t estimate the number of crayons in a box, t-shirt sized estimates were born and make sense…to them. But they make zero sense.
Because they are lies.
Any estimate that is based on the entire premise of “not enough information” isn’t an estimate. It’s guesswork, it’s a swag. But, more specifically, t-shirt sized estimates are just flat out lies. Of course, in reality, “educated guesses” and “swags” are lies too, but because we’ve come up with descriptive terms and uses for them, they get accepted as some semblance of the truth, and that semblance is one too many people far too often forget is based on guessing, and not estimation. T-shirt sized estimates are even worse, in that their entire premise and reason for use is predicated on a lack of information. In other words, their entire existence is owed to flaws and lack of information. Its like trying to take The Nothing from The Neverending Story and turn it into something…but with no Luck Dragon. So what can you extrapolate from nothing? Lies. Sure, you as the estimator don’t mean to say them as lies, but what other choice do you have based on what you are presented in these situations? And yes, we’ll all refer to them as educated guesses, but lets stop offending educated guesses by lumping them in with uneducated backwater attempts at creative problem solving.
But what becomes worse than the lies that are asked for in t-shirt sized estimates, are the lies this process completely and utterly guarantees.
Think about it. A client or Producer/Project Manager comes to you, without a PRD or spec doc, gives you a vague and (in reality and most likely) completely incorrect overview, then asks you how long it would take to design, build, test, and deploy. Uhhhh…Extra Large? WHAT THE HELL DOES THAT MEAN! Nothing. Given that scenario, any engineer will think of all the edge cases, the projects that they’ve been burned on in the past (even those that aren’t related or similar to the task at hand, because how would they know otherwise given no information?), all the unknowns, then realize there are unknowns they don’t know, then sprinkle in all the organizational problems in process and requirements gathering, and how could they not end up with an XL or XXL t-shirt sized estimate? No one who has been in the game long enough will want to underestimate in that scenario, nor would they want to over-promise. All that ends up meaning the only logical conclusion is to explode the estimate based on the lack of information. Or they’ll just pick an answer from the available options. Which means the estimate means complete and utter nothing.
Now let’s add in the other part of why this estimation process is the domain of inept kings in middle-management: this is poison in an organization. Any engineering organization needs good estimates to forecast work and availability, to plan, to assign resources, to balance work load, to reduce insanity, and instill trust and confidence in themselves and other parts of the organization, as well as the ability to improve estimation processes and identify efficiencies over time by having historical data and records to evaluate. Additionally, all engineers need to be able to understand the ramifications, ripple impacts, and inputs they need in order to do their work, not only for their own sanity, but for the overall project, as well as their career growth into senior positions and leadership roles that can teach others the nuances of these types of processes, which leads to overall improvements in the organization. Not to mention the fact that bad estimation, missed dates, are cancerous and an extremely slippery slope. Once others, who rely on the estimates provided by engineers and technology, see enough of those dates slipped, they stop believing any estimate that comes out of that group or team. But, more to the point, over time this erodes their belief in anything this team tells them. It introduces doubt at all levels of interaction. Then, add the timeline of projects to that and eventually the Producers or Project Managers will predict failures (since they stopped believing you) and be right. They added 4 weeks to a plan because they’ve been burned before, or they held off the start of another project because they knew this project would eat resources longer than expected, etc. And then it happened. Now they’ve validated their lack of faith and trust, all while having evidence they can use to justify this lack of trust, to themselves and to others in positions of power, and now they’re off and running. They are justified in not believing you at this point, they’ve saved projects because of not believing you, and now this tendency is going to very easily become part of their culture and one that they are rewarded for (either directly or indirectly), and a cultural facet that will take months, if not years, to chip away at in an effort to prove the best practices of any technology organization. I’ve seen it over and over again in engineering organizations who don’t enforce and teach good estimation processes.
Now, this isn’t all to say that if an organization isn’t doing t-shirt estimates then their estimation process is fine, or that these other issues I touch on can’t happen either way. That’s completely untrue. Good software estimation needs to be a pervasive force in the culture of a high-performance engineering team, and if it isn’t and whether or not it uses t-shirt sized estimates, the very subtle and very poisonous things which t-shirt sized estimates and generally bad software estimation lead to can and will still happen given a long enough timeline (especially in fast-moving shops, or shops with multiple concurrent projects, or shops with shared tech resources, etc.).
Estimation needs to be based on facts, truth, and documented guarantees when those are not present (and I would only say the latter when working with people I’ve come to know and trust over the years and dozens of projects). Lack of information is not an opportunity to pretend the information is there and make things up, but this is exactly why the people who tend to offer up this type of estimation think (incorrectly) that they are coming up with a creative solution to a problem that lets the team keep moving ahead. They are wrong, and so woefully shortsighted that they should never be in a position to force this kind of estimation.
Lack of information is a lack in process… fix the reasons why an estimate is asked for when the required information for the estimate is missing (and make sure you, as a member or leader of an engineering organization, have documented and explained what you or your team need in order to make good estimates), and then estimate properly, with all the rigor and due diligence that goes along with it.
If you just want to make shit up and ensure failure…well, I can think of a few companies where you’d fit right in.
Otherwise, if you’re going to play the game, play to win. There are a multitude of things that lead to and support good estimation, as well as a multitude of things that good estimation lead to and ensure. Everything is connected. Recognize that, think of how things play out and causality, and don’t accept faux attempts at intelligence or problem solving. Instead, push and help grow whatever group or team you are in to be better. And if you aren’t at that level where you can weigh in on good or bad process…get there. Play to win. Or find a different game.