I gave a talk entitled “Time-Based Estimates Are For Suckers! Size-based is The Way to Go” at this year’s GLSEC on April 29. It’s meant as a call to action for those who haven’t made the leap to size-based estimation, or who have been beaten back by some of the challenges you’ll encounter when trying, such as:
- Breaking things down by value, not by task
- Thinking in terms of “size” (not time)
- Making estimates
I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.
(Nevertheless, I didn’t design the talk to actually teach the skills needed to fully implement size-based estimation and planning. For a better-articulated discussion on how complexity-based estimates actually work and on why and how to start using them, see Carl’s series on Making Better Estimates.)
As a tail on the conversation, I prepared some common high-level concerns and roadblocks to discuss, but the audience in the room provided plenty of same-level questions. A good example was, “How does all this data-driven re-estimation help me when I’ve got a fixed timeline that cannot change?” Answer: “This is one of the best tools to know if you’re going to get done on time; your manager will thank you for sharing that information early.”
I also had a brief tangent where I had to admit that Atomic does, in fact, use time-based “Aggressive-but-possible/Highly-probable” estimates during the sales process, when sketching high-level time-and-money estimates, since it assists with bidding and budget setting. But these estimates are then decomposed further using size-based tools for tracking and management.
Some common questions I didn’t get to in the talk:
- When is a story “done”? (When the customer says so, or when you’re able to demonstrate the value has been added.)
- Should estimate and track points for bugs? (Depends on what your customer is planning around; bugs aren’t scope, but they take time. Best to tackle them regularly and let them affect overall velocity.)
- Will customers accept estimates given in points? (Maybe eventually, but don’t force anyone to understand or accept your point scale. Instead, derive an estimated duration and be ready to explain how size and velocity create that information.)
I actually hope to continue the discussion. Size-based estimation — far from being old-hat or a close topic — is still the kernel of any great software project management process, and it still takes care and effort to keep the furnace stoked with good input.
Here are the slides from the presentation: