February 26, 2021
This post is updated with the discussion here.
Estimation and/or pointing has three purposes:
- To generate discussion within the team so people have an idea of the complexity of the work and are aligned on what it takes to get the job done, and what the general approach will be. It's the main reason we have story points - to see how aligned people are in their view of the work. It generates discussion and that conversation is by far the most useful feature of story points.
- Capacity planning - this is usually a Scrum thing. I have honestly never seen this done right. Ever.
- Forecasting - management just abuses this and we should try to stay away from this because it gives the illusion of accuracy disguised as precision.
The first is easily the most useful part and the second and third are rarely useful, and often harmful for many reasons.
If we do want to do estimating, I recommend reading the Ron Jeffries (the guy who invented story points) who has a nice blog post about the pitfalls of story points and how when he came up with the idea it was mainly about developer focus.
I have tried pulling predictability out of this and I have found that the pre-conditions required to do that are rarely there.
How open is the culture in the organization to a communicated date changing? If the prediction is off, does it set off panic mode along with countless explanations of why the date changed? Do we have to do variance analysis which invariably involves some story point math to justify the new date? Do we point fingers at why we were “wrong” in our first predictions? If the culture in the organization is open to change, then sure, make some predictions knowing that there is psychological safety in case the predictions are wrong. That level of trust and culture are hard to create. Don’t get me wrong, at the team-level with the developers, designers and BAs, everything is good. It’s at a higher level where these predictions are taken as stone way more often than not, and any change to them ends up reflecting poorly (and unfairly) on the team.
The other, much more deeper question is, what is the investment in forecasting (and it is quite a significant investment) buying you when it’s going to be mostly a guess anyway? Usually, this is tied to budgeting and resource allocation and there are much better ways of going about that like the Beyond Budgeting Principles and the work of Bjarte Bogsnes.
If there is a need for predictability, it is in my view best achieved by analyzing Cycle Time and Throughput (i.e., how many days does it take from requirement to production, concept to cash). However, even that’s not predictability, those are continuous improvement metrics which you can rejig to get some predictability.
So, in short. I would question the need for predictability, because predictability has a cultural and economic cost which may not always be worth it.