I generally try and stay out of conversations and debates about estimation techniques in general, because I have a set of strong opinions that are almost outside the context where the questions arise, and the mere hint of a #NoEstimate tag brings out the trolls en masse. However, in response to a question from Bhanu Chander Golconda on LinkedIn, I started writing a brief response in a comment and accidentally wrote a blog post instead. Here it is. Opinions? LinkedIn, here.
The original context was a question about if you estimate defects in Scrum, and I said “No, because I don’t estimate in story points.” Bhanu asked “Just curious, do you estimate, if yes is it in different unit?” and I realized that there wasn’t a quick simple answer that serves. Why? Because this dives deep into the philosophy of estimation.
There are three reasons to estimate in my mind, listed in order of importance:
1 – To help determine if the work is worth doing in the first place. This estimation I turn around and ask “how much are you willing to pay for that value?”, which lets me estimate as “this is obviously cheaper than that amount, so of course we’ll do it”, “this is obviously more expensive than that amount, so we don’t do it”, or “it’s going to be close, we should refine the estimate, or maybe just treat it as too expensive anyway and move on”. This estimation is done in big round number dollars or time (because team time converts directly to dollars)
2 – To help the team tease out misunderstandings (within the team, including the PO) about the purpose, intent, and likely design of the work. Planning Poker can expose those, so it’s useful. I would typically use story points for that if the team knows them (because that’s what’s on the cards, right?) and then throw away the answers once the team converges.
3 – To help the team decide if it can fit the work into the current iteration with any degree of confidence. My first pass on this is historical story-count (not point) velocity. My second pass would be the wince test of team confidence. Only if there are multiple critical fixed-date stories do I move towards point estimation, and that only to know if I need to pull capacity from other teams to finish. If the answer of “we can’t fit it” isn’t “we’ll empty another team’s backlog and do it instead” then the answer clearly isn’t important enough to require an accurate answer.
Note: Most of my opinions above scale up as well – Features, capabilities, and perhaps even epics. However, at the bigger scales, especially epics, more financial analysis is almost always warranted because the decisions amount to millions of dollars. A team-level story costing a few thousand, or a feature at under 100k, doesn’t warrant excessive precision or overthinking in most budgets.
