Estimation basics
Betterplan estimates the size of a Story in Story Points. This chapter explains the principle. Estimating in the interface itself is described in Estimating.
Story Points are relative
A Story Point has no unit like hours or days. It is an abstract size that expresses the ratio between two Stories: if this Story is twice as big as that one, it gets twice as many points.
This works because you can judge size ratios quickly and reliably, even without knowing how long something takes you. Two piles of sand: you see at once that one is about five times as big as the other. How many hours the shoveling takes, you only know after you have cleared the first pile.
It follows that:
- The first number in the backlog is the hardest. It is the reference point for everything else. After that you compare: twice as much work as the 3? Then an 8.
- Relative estimates are robust. If something affects all Stories equally, the ratios don't change.
- Differences uncover misunderstandings. If two people estimate the same Story very differently, they apparently see different amounts of work. That is worth a conversation.
The scale
Betterplan offers a Fibonacci-like scale: 0, 1, 2, 3, 5, 8, 13, 20, 40, 60, 100. The gaps grow with size, because the bigger a Story, the less precisely you can estimate it. If you are unsure at an 8, take the 13. The uncertainty is then already built in as a buffer.
User Stories are estimated. Project and Devteam Stories and Workitems carry no Story Points, see Story types.
You don't have to estimate everything
This is one of Betterplan's most important properties: every User Story without an estimate of its own automatically gets a provisional value. You don't have to estimate every Story in order to plan.
The reason: a new Story has the least information it will ever have. Estimating it precisely now costs time and yields little. So Betterplan provisionally counts with the median of all estimates so far in the project. It is robust against outliers, learns with every estimate and, from experience, becomes dependable from around 30 estimated Stories. You see it as ≈ on the card and can override it at any time with an estimate of your own.
The consequence: your Backlog is estimated from the start, and forecast, Timeline and cost work immediately. Estimate a Story yourself as it matures, at the latest on the way to Ready. How this looks and how you step in is covered in Automatic estimates.
Velocity is not speed
Velocity is the amount of Story Points your team typically completes per iteration. Betterplan takes the average of the three most recently completed iterations. From the sum of points and velocity you get duration and forecast (see Forecasting and Progress).
The term is easily misleading. Velocity does not mean pure speed ("How much did we work?") but speed with direction: "How close do we get to the goal?" Two rules follow:
- Only delivered Stories count. A Story counts only once it is Done and Closed. Canceled Stories deliver no points.
- Only User Stories count. Bugs, refactorings and other technical work don't bring the team closer to the goal. They run without points so that velocity stays clean.
Keep your velocity clean. Only then do bottlenecks and real progress become visible, and only then is the forecast reliable.
Velocity is the team's planning basis, not a comparison between teams and not a target. Once it becomes a target, teams estimate more generously and the number loses its value.