Estimations don’t have to be a painful process, take a few minutes to learn how we approach them.
- ⏰ Don’t estimate time
- 🤓 Estimate effort and complexity
- 🔍 Be generous with Story Points
A typical scenario runs like this: Developers are asked for estimates, they have not enough information and are too optimistic, so they underestimate. Someone monitors those estimates, and everyone is upset when something takes longer. Surprisingly everybody hates estimations.
Why do we estimate?
Estimating Stories in a Team starts insightful discussions. About the feature, implementations and pain points. You’ll see how this improves the collaboration.
Estimates help to make significant decisions. Every Team member has a slightly different focus and thinks of the complexity of own tasks. Discussing estimates helps your team members to get an understanding of the overall complexity.
What are Story Points?
Story Points are a subjective unit used by Agile teams to estimate User Stories. Story Points don’t equal hours or days. They are related to effort and complexity. A typical range is 0–100 Points, but you should be generous and not too picky when it gets complex. Many Teams only use the numbers 1, 2, 4, 8, 16 and so on. Other Teams use Fibonacci numbers 1, 2, 3, 5, 8, 13 and so on.
How much is one Story Point?
That depends on your Team. It’s a subjective and relative unit. When you start estimating your first project, pick any number that feels right. With your second Story, compare it to the first one. Is it the same effort or double the effort? With every Story, your Team gets a better understanding of the value of one Story Point.
Who should be involved in Story Point estimation?
Estimation shouldn’t be a one-person show. You want your whole Team to discuss to receive better results and to develop an overall understanding.
Why are Story Points better?
You don’t want to discuss hours or days. If something takes longer than the estimated time nobody is happy in the end. You should discuss the feature, the effort, and the complexity.
Bonus: Planning Poker
You know about Planning Poker? A lot of Agile teams play Planning Poker to estimate stories. They discuss a Story and every Team member estimates the complexity. You can use playing cards, apps or just pen & paper, but don’t reveal your estimate until everybody wrote theirs down.
Then reveal the results at the same time. The two team members with the highest and lowest estimate discuss their reasons. They are both able to change their estimate, but they don’t have to. In the end, the highest estimate wins. Team members who see the highest complexity have the most significant impact on the estimation.