Estimating

software estimating is a part of Planning - trying to break down your work backlog into pieces so you can predict how long it will take to work, and also make trade-offs for Time Boxing.

Actually, part of the confusion in debates about Estimating comes from different purposes for estimating; and part comes from different scales, from Engineering Task to whole-Project.

Dread Pirate Crom on the value of estimating Engineering Tasks.

one method: Story Points - http://blog.anandvishwanath.in/2011/03/questioning-story-points.html - Story point estimation is done using relative sizing by comparing one User Story with a sample set of already sized stories. Relative sizing across stories tends to be much more accurate over a larger sample, than trying to estimate each individual story for the effort involved. So, your Velocity is in points/manweek or such, and you hope that velocity stays pretty smooth. Of course, you still have to (a) prioritize your work (Development Queue), (b) break it down into stories, and then (c) estimate each - how far out in the future is that worth doing when doing Agile Software Development?

Jul'2012: Chip Morningstar notes that Over the years I’ve learned that I often have to train people I’m working with on the distinction between three related but very different kinds of forward looking statements: plans, predictions, and promises. In my experience, somebody treating one of these as one of the others can be a significant generator of interpersonal discord and organizational dysfunction... Plans are about intention; Predictions are about expectation (Model); Promises are about Commitment.

Jul'2014: Allen Holub: Unfortunately, looking at points in a destructive way is actively encouraged by some tools. Pivotal Tracker, for example, wants you to "assign points" to every story and then tells you how many of those points you complete in some time frame. You're supposed to complete N points per week, for example. This is just a complicated way to do the whole estimate/deadline thing I was discussing in the last post. It's fundamentally wrongheaded... Given all that, I'd be just about ready to toss the whole notion of points, except that effort is an important input to the prioritization process. For example, a story with high effort but only middling business value should be pretty low priority. (E.g. put blue lines around every box on the website: a lot of niggling effort that won't impact the user's life one iota). So, I think the best solution to this conundrum is to get away from the numbers entirely. I use words. First, I call the measure effort, not points, just to get away from numeric thinking. Then I choose meaningful words to represent levels of effort. For example: trivial, easy, normal, hard, herculean, unknown. I often just bucket idea-candidates as A/B/C on both value and cost (A = best, so highest-value or lowest-cost), then I sort on value-then-cost...

• No Estimates
• Lesstimating: I like this framing

cf Fermi Estimation (order-of-magnitude, cf SWAG)