Principles
- Using estimates is mostly just a forcing function for a team to have (better) conversations about:
- How complex is this piece of work?
- Is the scope too big/risky? Should we break it into smaller, more easily estimable chunks?
- Are we taking on an unrealistic amount of work in the next cycle?
- The conversation itself is more important than the outcome (the number of points allocated).
- The points estimates themselves should be considered virtually useless outside of that team (and even within the team, only really relevant to the last couple of cycles). They are definitely not a useful metric for comparing performance between teams. Even if they were able to predict output, we care far more about outcomes than output and story points will never be able to effectively capture that.
- Estimating chunks of work (issues) often helps teams to better predict when chunks of work might be completed, but the two are not directly related:
3 points ≠ 3 days. - In smaller companies, it can be helpful if multiple teams opt to use the same methodology when trying out estimates (e.g. they all agree to use the Fibonacci points system): this makes it easier to share best practices and for individuals to rotate between teams without needing to adjust to a different ‘language’ for estimating. But even if they do, each team will probably use the points estimates slightly differently, and that’s completely fine. And estimates are pretty easy to get the hang of, in any event.
- If a team does not have an established process in place, I try not to overwhelm them by introducing the concept of points-based estimation too early. I'd rather they get used to a tool like Linear and switch on estimation if/when they feel it would add value.
My personal preference
I don’t have a strong personal preference, but if you were to press me, and considering Linear’s available options for issue estimation:
- I prefer numerical estimation. I think it makes it easier to spot when we are being wildly ambitious about what we'll get done. For example, if our team of 4 typically gets through 30 work points in a cycle/sprint, but the next cycle/sprint has 60 points allocated, something is probably amiss.
- I prefer non-linear estimation. It forces us to have more pointed conversations about the size of complex features because the upper end of the scale (e.g. 8 Points for Fibonacci; 16 points for Exponential) is significantly larger than the smaller end (e.g. 1 point).
I’ve had the best results using Fibonacci: I think it hits the sweet spot.