Story points were invented by Ron Jeffries (more about Ron Later) as a simple way to indicate the relative complexity of one story against another. A story can be thought of as perhaps a new feature being added to software or perhaps even a bug fix. However, they are often used (mistakenly) by some people to estimate how long it will take to build a feature.
I know some people love ‘Story points’ but I think they are a terrible idea for the following reasons.
As soon as a development team realise that story points are being used to track their progress (and essentially their effectiveness) it would not be unusual for them to over estimate in an attempt to make themselves look better. Who would blame them.
If you are running a very small team, I would wonder why would you waste time coming up with some fictional number rather than just agreeing as a team that you think we could deliver ‘Next Friday’ if all things went well. Also, estimating how long it will take to build a feature is very, very difficult.
A new feature might be easy, but you might also discover that this new feature breaks another part of the solution. Or, exposes a security risk or it even turns out to be the wrong thing because the business described what they wanted poorly.
Also, development teams tend to be interrupted very regularly, based on other things that are happening in the business. For example, a critical bug occurs , and it’s an “all hands to the pump” to rectify. Or, a critical feature really, really needs to be built because the sales team can’t sell without its addition. Or indeed, it needs to be delivered now because the sales team has already over sold it in the past.
Stopping and starting development often adds additional time onto the task. If you stop developing a feature and go and do something else, you have to spend time getting back into context, to remember what you were doing, when you return to the work.
Consider, also, some developers are simply better than others ! Maybe this is just because they have more experience maybe they have worked on this piece of code before. Alternatively, they may be new to a project and are still in the learning curve.
In addition, the team may vary relatively regularly, particularly as churn with developers is not at all uncommon.
So, for small teams there is literally no good reason I can see for inventing these numbers. I’ll talk about better way of estimating later, but before that I’d also like to add in why I think story points dont work for bigger organisations either.
In a larger organisation, they are likely to be running multiple teams. Probably on different software components and almost certainly in multiple regions. They will employ local resource and may well offshore parts of their build to external teams.
As they probably want to standardise on reporting they may well be tempted to use story points almost like a metric measure. They might also use this a method of comparing teams to see which teams are performing better than others.
In my view, this is the worst of all possible evils. It has the stench of Taylorism about it. In fact, it is worse as I don’t believe you can measure a standard unit of software development in the same way in which you might measure how many bricks could be laid in an hour or how many Big Macs can be served per worker . Software development is too complex for that.
So , comparing team A’s velocity (the speed at which they get through story points) with team B’s is meaningless. It’s not only meaningless, it has the real possibility to de-motivate the very people you find it hard to hire.
In addition, the manager of the team will probably know that the estimates are being over estimated. However, as these stats are now on a balanced scorecard, reviewed by their peers, they will not put up much resistance, In fact, they might even encourage more slack to keep the wolves at bay. Who would blame them.
Now we have a detached emotionless metric to measure the output of an emotional team. People can hide behind the numbers and in doing so are going to be less focussed on the ultimate prize, which is the customer. They will be mucking about with graphs which are detached from their own people and what they are trying to achieve.
Estimation and Agile
Agile development is one of the most effective and revolutionary things to have ever happened in the software development world. I’m a big fan. If you have never read the Agile manifesto, you should check it out here.
One of the main benefits of Agile is the ability to be very flexible in the order in which work is carried out. It is relatively easy to re-prioritise and deliver stories in whatever order you like (assuming no dependencies). This, in my view, is what matters.
Even though you might be working towards a large release with a relatively fixed date. It is always better to prioritise functions to keep the date intact rather than moving the date. So, with Agile , you can prioritise on a sprint by sprint basis what functions absolutely must get done and others that might not make the cut.
The best way to manage that is via frequent communication with the development team, the business and every stakeholder who has an interest. Sometimes this is called ‘Blink Estimation’. Basically you get as many subject matter experts into the conversation as possible and ask them questions about ‘roughly’ how big do you think the task is.
Remembering that is is an estimate, not set in stone.
It is important to seek opinion of wider stakeholders group at start of estimation project. For example, the developers might estimate it as being a smallish task but a security expert might recognise high levels of PCI audits or injection attack testing etc.
This is best achieved when all the team trusts each other. I think, establishing a trust network far outweighs the advantages of some random arithmetic based around story points.
Once you have an estimate, you can go forward on a ‘best endeavours’ approach, varying the task priority in line with the holistic project and all it throw’s up. But you do it as a team. You all work towards a shared goal were everyone is treated with respect within the team.
As I mentioned earlier , I like to get back to the Story Points inventor Ron Jeffries who, as it turned out, declared in 2019:
I like to say that I may have invented story points, and if I did, I’m sorry now.
Ron Jeffries
I’m not a big fan of story points. So, I say again “Gonnae Nae, Gonnae Nae !”.
“Gonnae nae dae that, gonnae nae !”
Scottish (Glaswegian) slang = Don’t do it.