In my coaching experience, I usually find teams struggling to truly understand the purpose of estimation. It is important to get the basics correct before chasing after other concepts, such as "relative" or "story point" estimates. So let's begin with the basics. All of your thoughts and suggestions in response to these thoughts will be welcome.
Here's an example: If a user story team is able to complete their work in 10 man-days (as per the DOD), it doesn't matter whether we estimate 6, 8, 10, 12, or 14 days. It will likely take 12 man-days, won't it?
Then why are we estimating?
Let's try to get an understanding why we need to estimate, and for whom we are estimating.
An estimate will help the PO to:
- Prioritize user stories. For example, user stories "A" and "B" will save 50K and 40K euros, respectively, for the end user. Obviously A is a higher priority compared to B. Our estimate is that A and B will take 50 and 10 man-days respectively to accomplish. This is a trigger for the PO to recheck the priority and set the stories in the product backlog accordingly. Here is an illustration:
||Priority after estimates
- Communicate “tentative” delivery time to the end user, which helps market the product.
An estimate will help the team to:
- Plan/commit what they are able to deliver in the sprint, release, and year (with some variation, say ~20%, depending on the team).
Estimates are not
Estimates are estimates, not actual effort.
- Questioning the dev team in case of delay or a difference between the estimate and reality.
So, estimates have an important purpose.
Now, if we are clear why
we are estimating, let's think further about our purposes.
- How much time is really useful for estimating any story?
- How much accuracy do we want in our estimates?
It is obvious that the more time we spend on analysis and prototyping, the more accurate estimates we will get. But is it really worth spending more time on user stories that are of low priority, or that aren't planned for next 2 to 3 months, or that may even be dropped eventually, due to reasons of scope?
It is always wise to have a balance between accuracy and time spent, instead of striving for ever-more "accurate
estimates. Fortunately, Scrum/Agile has came up with a better approach. I will further discuss this, in the form of "relative estimates," in an upcoming article.