Like many of you reading this, I occasionally browse Hacker News. Often, these ventures lead me to articles about software estimation and its inherent challenges.
Estimating software can indeed be tough. To address this difficulty, various strategies have been introduced. However, in my view, some of these strategies only compound the complexity.
For instance, "T-shirt sizing" tasks (Small, Medium, Large) or assigning story points (1, 2, 3, 5, 8) can create debates and confusion. Wouldn't it be simpler to just say, "it should take half a day"?
What's the First Question You're Asked?
If your team uses story points for estimation, you've likely been asked, "how much time does a 3-point story take?" And you might have responded with "a day or two, depending on the challenges." Why not just give a time estimate right from the start?
Imagine if you asked about the duration of a loved one's surgery and were told, "it's a 5-point surgery." That wouldn't be helpful, right? You'd want a concrete timeframe.
Or consider a contractor remodeling your bathroom. If you asked when it'd be finished and got "it's an 8-point bathroom" as a reply, that wouldn't suffice.
Estimate in Real-Time
So why make software estimation more convoluted? Provide your estimates in hours or half-day increments, always noting that these are just estimates. Sometimes things arise that slow progress, while other times, things might speed it up.
If uncertainty is the primary worry, consider cushioning your estimates. Start by quoting in half-day units. If a task seems like a 2-day job, extend it to 3. If it feels like 3 days, make it a week. For tasks spanning more than a week, break them down further.
Ultimately, this approach means you can state, "we've estimated 34 days of work," rather than "we've estimated 140 points." The first gives a tangible framework for planning, while the latter is ambiguous, and often, someone ends up converting those points back into days or hours. Let's keep it straightforward from the get-go.
