Story Points Considered Harmful? 1 of 4 - Journey's Start
Join the DZone community and get the full member experience.Join For Free
Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
(Warning: this is the first of 4 blog entires, its quite a long post. Plus I think there are two appendix blog entries to follow up.)
Now I’ll admit, when I first heard this argument I thought “Well I can guess where they are coming from” - I have sympathy with the argument, I’ve always considered story points as suspect myself. I also thought “But I don’t think they are right”. Specifically I know a team who use story points and claim to be able to schedule delivery “to the day.”
I’ve collected some data of my own from teams I’ve worked with, am working with or at least in contact with and done a bit of amateur analysis. I’m also taking time to go over Vasco and Joseph’s arguments.
This is a big topic and its going to take me a while to get to the bottom of the data, what I think and the pro and con arguments. So please forgive me, this is going to take a few, possibly long blog articles to go through.
Lets get a couple of things on the table to start with.
Firstly I don’t believe Story points are a Scrum technique. Yes they have been subsumed into Common Scrum but I believe they originally originated with Extreme Programming. Where they originated isn’t really important because I believe story point estimation and tasking (i.e. estimating work to do with story points and then scheduling a number of story points) is at odds with Scrum Commitment.
I’ve blogged about this before, Two Ways to Fill and Iteration, so I won’t repeat myself. Just say, in my book commitment and story pointing are alternatives.
By the way, the name Story Points comes from Mike Cohn, I prefer to call them Abstract Points, and I’ve heard others call them “Nebulous Units of Time”.
Second, I don’t believe story points can ever be stable if you don’t have a stable team. If you remove people from a team I expect it to slow down, if you add people to the team I expect it to slow down too - at least in the short term. In the longer term you might increase capacity but frankly I don’t know how long that will take.
I few years ago I worked with one team which had story/abstract points which appeared to be random. When I adjusted form changes in team staffing they average was constant. That said, I don’t expect points to remain constant, they might do for a while but I expect them to fluctuate at the very least.
It goes without saying that I expect sprint/iteration length to be stable too.
Which brings us to the third thing: with points, stories and projections, they only work at the average and aggregate level. They are a good predictor over several sprints but they offer no guarantees for the next sprint/iteration.
Finally, for now, something I do agree with Duarte on: we can’t estimate. By “we” I mean humans. Last year I devoted several blog entries to the subject, Humans Can’t Estimate.
Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.