I’m sure I’ll take some flack for this, so in the spirit of saying something controversial to promote discussion here we go.
“Story Point Suck, please don’t use them”
OK, let’s clarify that before the local scrum villagers come up with flaming crosses and stakes to drive through my heart, although I have been referred to as Nosferatu before, thanks NHS Digital and Adrian Bell in particular. 🙂
Let me just start by saying context is king, so perhaps what I really need to say is that there are times when Story points aren’t some kind of secret sauce and you really do need to stay well clear, so perhaps this should read
“Sometime Story points Suck, then please don’t use them.”
And if you don’t know whether this is one of those contexts, the don’t use them until you do.
I lived in Perth, Australia for about 7 years and I whilst there I learnt to surf, one of the first things you learn is not to paddle against a rip (tide), go at right angles to it, until you pop out of the side and then you can then paddle back in much easier.
If you paddle against the rip you get tired quickly and before you know it you can be a K off shore and in trouble, this is from experience by the way.
I’m going to suggest that there are certain types of organisations, that are very “traditional”, hate the word, in their outlook and especially in the way that they seek to deliver projects1 and that these are the kinds of contexts that you may just want to stay clear of story points, certainly initially at least.
When you start with new teams in these organisations, you have two ways of going, one is hard Agile, a bit like a hard Brexit I imagine, a kind of hard Agilexit, that’s really bad isn’t it, sorry!
In these types of environments I tend to find that story points can simply scare the hell out of anybody remotely senior. They don’t get them, they don’t want to get them and to be honest you are taking them out of their comfort zone and frightening them half to death and this just make resistance to change, even the passive aggressive resistance to C-level mandated change more, well, resistant.
The teams themselves are probably fairly used to providing estimates in hours or days anyway and to be frank there are much bigger fish to fry, like simply making the work that they are doing visible, remember S.T.A.T.I.C2 is your best friend.
In short you are paddling against the rip if you try to use story points here, you’ll end up exhausted, when you need your energy for bigger, more important battles.
Actually mostly development teams are not the major issue as they work fine, the problems lie mostly with the inability of many organisations to understand the what and why they are building what they are building, what is value for them, so the product space.
Or even their inability to be able to get code out of the door due to red tape, poor environments and relationships, so the DevOps space.
At times you really have to pick your fights and a hard-line broad brush approach to Scrum can be painful, so in the cases I use ideal days initially, remember you can still relatively size using ideal days anyway, it’s just less, well alien.
If as many people fear the estimates become promises and end up in Gantt charts and then become a failure to deliver to plan, then use it to your advantage. A strong example of why you can’t plan in contexts that involve knowledge work, mostly people are reasonable, well mostly, and they get eventually that you can’t be accurate with estimates for things you have never done before.
But honestly, Story points are a fight for later, sometimes.
So don’t just blindly use them and obviously the same goes for all our agile tools and techniques, context is indeed king.
1 I’m talking about knowledge work here, there are times when you are doing something simple and obvious that you can predict and you can therefore plan out upfront and its entirely the right thing to do.
2 Systems Thinking Approach to Implementing Kanban: https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson