Know the Purpose of Your Estimation

In agile approaches, we can use the team’s wisdom to create accurate estimates, up to a point. For me, the question is this: Who wants what kind of an estimate?

Your managers might need gross estimates to understand roughly when they could plan on having a feature set available, or when the project might end.

Your team might want to predict its capacity to understand how much it can bring into an iteration. If you use flow, you might not need to estimate anything. You might have to work with the product owner to explain how large you think a specific story is so the product owner can understand if the team’s historical cycle time is valid for this story.

If your team is willing to create stories of roughly the same size, you don’t need to estimate anything at all. You count the stories. Counting works even better when you have one-day stories.

I’m not talking about tasks. I’m talking about stories, value to a user of the product. In my experience, when a team starts counting stories, it realizes several beneficial side effects:

• The team creates and accepts stories of roughly the same size.

• The team creates stories that tend to become smaller over time, approaching one day or even less.

• The entire team understands stories across the product.

Consider counting stories for your estimates.