Agile Estimating: 5 reasons why we don't estimate in man-days

story points

Agile Estimating: 5 reasons why we don't estimate in man-days

You're sitting there with Planning Poker cards in hand and you're supposed to be guessing at those weird "story points." And you secretly ask yourself: "Why don't we estimate in person days?"

Because participants in CSM courses keep asking me exactly this question, I am listing the five most important reasons for estimating in relative size.

First of all, what are story points? Very simple: To know how fast your team is, simply count the stories (or features or product backlog items) they complete in a sprint. That is the speed of the team in this sprint, for example 9 stories. "Stop!" you will say now. “You can't lump all stories together. There are bigger ones and smaller ones.” That's right. Then we just let the big ones count double or triple or even more and the smallest ones only once. Each story gets 2, 3, or just one point. And hey presto we have story points, they express the relative size of the story. The velocity is now the sum of the story points of all stories completed in a sprint. And that's it.

But now finally to the advantages of relative estimates with story points!

Story points are more stable than time estimates

Scrum teams learn and learn much faster over time. With every new insight and every internal improvement in your work processes, you would have to re-estimate the absolute costs. Tightening the definition of done (a typical and highly recommended procedure) would also result in a reassessment of the absolute effort. Story points, on the other hand, do not change as a result. This means that you have to put far less effort into re-estimating product backlog items.

Teams estimate relative effort faster and easier

Estimates are – conjectures. However, absolute estimates often come with an implicit promise that a team must also be able to implement a feature within the estimated time. This often leads to cumbersome and very detailed discussions before an estimate can be agreed. To determine story points, on the other hand, there are methods that a team can use to estimate dozens of stories in a very short time.

Here's an anecdote: I once worked with a team that found the clarifying discussions on relative estimates to be so helpful that they used them even in very unclear situations in order to find a common understanding too quickly. They then rejected the resulting size estimate!

Story points are independent of implementation details

The absolute effort required for implementation naturally depends on who exactly does what. However, this cannot be determined sensibly long in advance. By the time the situation is actually implemented, it will have changed and the team has gained new insights, so the plan that makes the most sense will probably look different. Predetermining implementation details just for the purpose of estimation is a waste that we want to avoid. Story Points enable just that.

Story points are fault tolerant

Even if a development team does not take certain aspects into account when estimating, such as the automation of integration tests, story points do not have to be reestimated. As soon as the team realizes its mistake and also completes this work in the sprint, its speed decreases, but the relative size of the stories does not change.

Story Points combine expert knowledge from different areas

Different stories pose different challenges. Sometimes design is tricky, sometimes testing is difficult. These are all implementation details that are not relevant for the product owner when prioritizing the backlog. Story points abstract from these details and combine the entire team's knowledge into one estimate.