Story points, velocity and burndown charts are a total waste of your time as well as everyone else's time so stop using them, they are evil!
Even the creator of story points, Ron Jeffries, apologised for them on X back in 2019 for goodness sake. If you didn’t already know, Ron Jeffries is one of the founders of eXtreme Programming.
Now don't misunderstand me, of course we still need to talk about the work, discuss it, understand it and break it down. I'm just saying that using story pointing is not the way to go.
They've never been part of Scrum and lead to many bad habits and anti-patterns. So, like what and if not story points then what would you do instead? Well, let’s talk about it.
Before I get started I simply ask that you try and keep an open mind.
Now I know a lot of people think story points are invaluable and have been using them for years. I am absolutely not having a go at you. All I'm trying to do is show you a better way.
Have I ever used them? Yes of course I have, 10 to 15 years ago it was thought that they were a de facto part of Scrum but this is not and has never been true.
I used them for years largely because everyone else seemed to be using them and you were even taught how to use them in Scrum certification classes, even though they've never been mentioned in the Scrum Guide.
But I never really got any value from them and neither did the people I work with. Then about 9 years ago I had my eyes opened, but I'm getting ahead of myself, I’ll pick up on that later on.
Now using story points and velocity can lead to many bad habits and anti-patterns such as;
Comparing story points between teams
Thinking that increased velocity means a team is performing better, or worse still, that they are providing more value.
Deferring to a senior member of the team or simply the one with the loudest voice to set the points level
And let's not forget inconsistency. Because story points are relative and assigned subjectively different team members may assign different values to the same story and this can lead to inconsistency and make it difficult to compare estimates across different stories or sprints.
And burndown charts are as bad if not even worse, why? Because they encourage you to complete all the items taken into Sprint and are often used to beat teams over the head for not making enough progress.
Tools such as Jira make the problem even worse and in many ways encourage the wrong behaviour.
This is such an anti-pattern don't focus on completing everything taken into Sprint focus on the Sprint Goal, that is the important part.
Now if you can't create a Sprint Goal then you should really consider if Scrum is right for you, it is likely that Kanban would be much better choice.
Using story points to estimate your work is irrelevant because effort time does not equate to delivery time. One of the main problems using this approach to plan your Sprint is that story points are a measurement of effort and in general the effort that your team takes to finish something only represents 5 to 40% of your total delivery time.
If we break down the elements that contribute towards the time needed to deliver your work usually at least 50% of it consists of waiting time in the system, due to dependencies bottlenecks, expedite requests and plenty of other sources of inefficiency.
This is a realm that you can't predict by intuition.
So a massive flaw making story points estimation an unreliable approach to use is that it doesn't take into account the waiting time in your workflow.
Ok now 9 years ago I read Vasco Duarte’s book, ‘No estimates how to measure project progress without estimating’. Vasco is from Finland so it's a must read, why is that? Well, because I've just come back from Finland and the Fins are awesome.
Three names for you Raikkonen, Hakkinen and Rosberg, Keke that is not Nico.
Ok so that will mean nothing to you at all if you don't follow Formula 1 racing but trust me they were all amazing world champions, true dat!
Then I read Daniel S Vacanti’s first book on agile metrics called, ‘Actionable agile metrics for predictability’ and that changed everything for me and those I work with.
I highly recommend you read both of these plus Daniels subsequent books, ‘When will it be done?’ and ‘Actionable agile metrics for predictability volume two’.
Now then, when the word ‘estimate’ is used it often means different things to different people and the thought of not estimating can stir some deep emotions and cause some very emotive reactions for many.
So let me be clear, not estimating does not mean that we don't discuss the work, find dependencies and constraints, break the work down or run small experiments to discover more. Of course we still need to do this.
It just means don't use story points and velocity to do this and don't track them using a burndown chart.
So if not story points then what else? Well data. What data? Flow Metrics such as cycle time, limiting wip, throughput, flow efficiency, work item age and Monte Carlo Simulation to forecast.
They are extremely easy to do and I’d urge you to try them out.
Now is it the Holy Grail? No, absolutely not!
The Holy Grail is delivering real value and positive outcomes to your customers regularly and faster than your competition.
Will flow metrics help? Yes. Yes they will.
Look, think, have story points really ever helped you or your team? Come on now think hard and be objective and importantly be honest, at least with yourself.
Has an eight story pointer ever really been eight times that of a one story pointer and has that ever really been of any value to you or the team?
And has it helped you with conversations with management, stakeholders or leadership?
Yeah look I know story points were only ever intended to be used solely by the team but did that ever work? I think not!
Management loved velocity for all the wrong reasons. Come on tell me that isn't true? That you haven't been beaten over the head to increase your velocity!
Right so run an experiment, remember them? Try out Flow Metrics. The worst that could possibly happen is that you lose a little bit of time but nowhere near as much time as you've already lost messing about with story points.
Now the best that could happen is that you find a better way of measuring what really matters, stop wasting people's time, learn something valuable about your delivery and open new and better dialogue with leadership.
Honestly, do leadership understand story points? Do stakeholders? Of course not!
And aren't you fed up of having to try and explain story points to people outside of your team?
My bet is that even the team are totally fed up with having to use them, particularly developers. Give it a go!
Commenti