Are story points really about value?
I used to
think story points were about work
When I started doing Agile, I was introduced to the idea of user stories and story points. They seemed pretty clear to me; user stories were defined pieces of work, and the story points was an estimation of how much work there was to do in each story. But after a while I realised there were some problems with this line of thinking.
For example, if story points are a measurement of work, then you should put points on all kinds of work you’re doing, not just user stories. For example, fixing bugs, putting in hotfixes, workshops, and so on. But then your measurements become misleading. As I talked about in this blog post I wrote a while ago, you then have a team that could be “earning” a lot of points, while not delivering anything of any value. If you have one team delivering 100 points of stories per sprint, and another delivering 50 points of stories and 50 points of defects, one is moving twice as fast as the other, in terms of progress towards a release. So it makes sense to put zero points against the defects and say the first team is doing 100 points and the second is doing 50 points.
Then I decided they were about value
So points are about delivering value, not doing work. Any work that is not delivering value (as specified by the product owner), in the form of progress towards release goals, does not count:
- it shouldn’t earn story points
- it probably shouldn’t even be a user story at all.
User stories should be about working valuable software. Anything else (training, workshops, defects, setting up your new computer, whatever) are just background tasks. You can track them in your own task tracking tool if you like, e.g. a personal Kanban, but they don’t go on the team board and you don’t write them up as stories.
But there’s a problem: the value isn’t realised
Recently I’ve realised there’s a problem with this thinking though. It assumes that as soon as a story moves across the kanban state from “In SIT” to “Done” (or whatever you call your Kanban states in your workplace), that value is suddenly and magically achieved. Of course, this is not the case:
- the story hasn’t been deployed to production and released to customers (unless you have a really mature Continuous Delivery system happening and stories actually do go to production as soon as you complete them, if so, respect)
- even if / when they do get released, nobody knows if they are of any actual value to customers.
To go back to our previous example, say you had two teams, one of which was completing 100 points of stories per sprint, of useless software that nobody wanted and didn’t get released to anyone, and the other was completing 100 points of stories per sprint that went out straight to customers, who loved the software. Would you say each team is equally effective?
Now I’m not at all saying we need to further complicate our measurements. The pretty minimal amount of estimation and measurement you do in Scrum is as much or more than enough for me. I’m just pointing out that everybody, especially product owners and scrum masters, need to keep in the back of their mind: software that hasn’t been released to anyone is inventory, one of the eight wastes of Lean. And software that nobody wants shouldn’t even be built in the first place.
