Monday, February 11, 2013

My concern about Story Points proved right!

This months PragPub Magazine contains a great article by Ron Jeffries called "Estimation is Evil". It contains a couple of great quotes I'd like to share, and also proves my concern about Story Points right.

In my previous post "Story Points vs Hours" about a year ago I wrote:
"The more unreasonable reason is that as estimates are hard to do, you put a metric on them that is hard to understand to get away with them easier. If you say that something will take three days it's easy to see if you were right, while estimating it will take three Story Points will keep you safe. Who are to say how long a Story Point is? Hardcore agilists laughs at such a silly question."
In Ron's article he writes:
"There are a number of ideas about how to estimate using something other than time. Points, Gummi Bears, Fibonacci numbers, T-shirt sizes. These were originally invented to obscure the time aspect, so that management wouldn’t be tempted to misuse the estimates. (I know: I was there when they were invented. I may actually have invented Points. If I did, I’m sorry now.)"
Wow! Reading that just forced me to write this post!

However, since I wrote my previous post I've had the chance to use Story Points and was pretty happy doing it. We started with the assumption of a story point being half a day. That way, when estimating, we could easily transform our estimates, and thinking about "half days" instead of hours made the estimations simpler. "Would you finish this is half a day? One day? Two days?" is more tangible and easier to answer than doing the same with hours.

The story point estimates keeps being translated to hours on another level though, and my most frequent question is what formula to use for that transformation now. That's alright with my though, I can stick with estimating in half days and calling it Story Points. I'm just not sure about the formula, is half a day 3 hours, 3.5 hours or 4 hours? We started with the assumption of it being 4 hours, but as we usually are faster than we estimate with that formula I'm about to lower it...

Well, back to the article... Here are some other great quotes from it:
"Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again."
"Anyone who has ever looked at a list of “requirements” has seen some items that were very important, and some that were—well—not so important. Not so important like 1/100th as important as the most important things. Not so important like downright bad ideas. There is a very strong “80-20” rule at work in requirements lists. The bulk of the value comes from a very small subset of the so-called requirements. So these other things aren’t “requirements” at all. They’re ideas, and some of them are not very good."
"It seems that “they” often want to know how long something is going to take, and how much it will cost. My view is that “they” don’t even know what they want, so we bloody well can’t possibly know how long it will take. However, “they” are often powerful and have the money we need, so we need to answer their question, even though we cannot."
It's a really long article, but well worth reading. You will find the full article here:
Estimation is Evil (PragPub)


Unknown said...

Firstly, the article you refer to is an article containing Ron Jeffries personal opinions and I do not see this as proof of anything other than Ron Jeffries personal opinions ;)

Secondly, the whole point with story points is that they shall NOT be used as a direct substitute for time as you described you have been doing (where one story point = 4 hours), so if you think you've been using story points, you probably haven't ;)

Story points shall instead be used as a relative measure between different stories. The way to use them is rather like "we think we will be able to complete these 3 stories all together in the upcoming week, the first task is easy, the second is about double as hard, and the third one is somewhere in between, and by putting relative points on them we can use thous as a measurement of velocity for our upcoming sprints, but we do not care exactly how many half days or hours each task takes, we just think we will be able to finish these tasks this week", rather than to say "the first story is 3 story points (which means x4 hours) and the second task is 6 story points (x4 hours) and the last task takes is 5 points (x4 hours) which is 56 hours which mean we will not be able to achieve this in one week even if it feels like we should"...

Story points is just a help to see if your heading in the right direction, they are not meant to be exact estimates. Exact estimates are in fact a paradox, because the whole nature of estimates is that they just are qualified guesses and not exact truths, and guesses are never absolute, so if you shall do them you can at least try to use a non-absolut (relative) measurement for them, and that is where story points can help....

And of course, in a perfect world estimation wouldn't exist. But very few of us live in a perfect world. So to be honest I think it is pretty naive to just say "estimation is evil" and think you will get away with it... Unfortunately pretty few stakeholders will probably consider to pay you if you haven't even a slightly idea of how much you will be able to deliver within at least the upcoming week or two... And until you will find a stakeholder that differs from that you can probably have pretty good use of story points if you just use them right ;)

Tommy said...

Hi Martin, great to here from you. Thanks a lot for your comment!

As Ron was part of inventing Points I think he's entitled to say what it is. ;-) But I agree with your definition too, they're not mutually exclusive.

And I also agree that I'm not using Story Points to full extent, but I'm using them in a way that works for me (and my organization). Using them at this level helps me spend less time estimating while still allowing the business to be based in hours. Give some, take some...

Also, Ron doesn't just say "Estimation is evil", he says a lot more than that. Nine pages in the PDF version of the article to be exact. :-)

Unknown said...

Well, if you of some reason think that Ron Jeffrie's voice is worth more than mine in this context, you can then read how he once defined story points: "Story points are a relative measure of the time needed to implement a story, borrowed from XP (as is the notion of story). They are intended to be a way of estimating difficulty without committing to a specific time duration, so that variances in team size or time on task do not affect them". Pretty much the same thing I said. So I never said Ron got story points wrong, I said you did ;) If you use story points as an exact equivalent measure as hours, why not just use hours? Or half-days? Why even call that story points?

And I also said that story point may CAN help you, but it doesn't HAVE TO, and if they don't, just don't use them, that is in fact to be truly agile (according to the true meaning of the word rather than the manifesto), that you are ready to use what is good for you and leave the things that are not... Ron Jeffrie, and all the other guys behind the agile manifesto, may have been persons that invented story points, but that doesn't mean that their words are law, nor proof for anything. The only thing that shall be considered as proof for you is what is working for you and your team, and that can be something completely different from what is work for me and my team. As soon as you put up absolute laws and idols you have probably already failed being agile.

Tommy said...

As I said, I agree with your definition, and I can add now that I agree with Rons old definition too. But I think it's notable that beside that definition another purpose was, at least originally, to obscure the time aspect.

I also said that I know I'm not using Story Points to the full extent, so why do you claim I got them wrong? I use part of the concept to something that works for me, in my context - isn't that agile? :-)

Unknown said...

You began this whole article with the words "concern about Story Points proved right". In this text you describe your story points as "being half a day". Half a day is an absolute measure in time, the complete opposite what story points was intended to be.

If you have been using story points just as a equivalent substitute for hours you are correct that you haven't used story points to their full extent, in fact my point is that you haven't used story point at all. You have just used hours and called them for story points. So the concerns you have about story points are in fact concerns about hours, not those relative story points that both me and Ron refer to as story points ;)

And, I am pretty sure that the quoted definition isn't old, but is what definition Ron still uses for story points, cause the cite was actually from a site where he was speaking critical about them ;)

Tommy said...

Hehe, you have a point there! But I would object to "half day" being absolute. It could be 9-12 or it could be 13-20, quite different amount of absolute time. But thinking "could I finish this is half a day" gives me a relevant estimate without saying anything about hours.

Alas, my managers require a formula to translate them, so I provide that. If could be compared with the velocity calculation of other teams, but my team is somewhat vague and differs from week to week, so velocity would be irrelevant to track.

Me saying that is was "Rons old definition" came from you saying "read how he once defined story points". It may very well be his current definition if you say that. =)

Unknown said...

In Sweden a working day is most likely 8 hours. Which means half a day is around 4 working hours. So even if you are not directly speaking about hours it still is absolutely equivalent to hours in the end of the day.

You say that your team "differs from week to week" and that "velocity would be irrelevant to track" because of that. This states even more that you have misunderstood the concept of story points. Read once more what Ron said about story points: "They are intended to be a way of estimating difficulty without committing to a specific time duration, so that variances in team size or time on task do not affect them".

Variation in team size is one of the things that story points is intended to address.

If we say, as in your case, that one story take one day, that will most probably only count for you and not for that much more junior developer on the other side of the room. For him the same story will maybe take, lets say, 4 days to finish. What would that mean if one story point would be around half a day? Well, both story points (hours) and delivered value will differ depending on who is working on the story. So, no problem solved.

If you instead say that one story takes one story point that can be one day for you but four days for that other junior developer. Story points are points of delivered value. If your team size vary your total velocity will differ, but you do not have to change the estimated story points. You have velocity as a measure to help you see how much you probably will be able to achieve this upcoming sprint with the current team velocity. You now have a measure of how much value your team can deliver and and you also have an estimation that do not have to vary if your team vary.

But... to make a long story short: Even I see problems with story point, but my concerns are rather that people have such big problems relating to them. Hours are so much easier to relate to, therefor almost everyone trying story points out for the first time, in some way or another, translating them into something that is totally equivalent to hours. Story points can be a pretty good solution for what they are meant for, but the problem for people to relate to them makes them often more of a problem that a solution. But if you really have to do estimates, and understand the concept of story points, they can actually be superior to hours, but the dividing line is subtle. Most probably it wont help you, and therefor it is probably better to just skip them completely...

Tommy said...

Are you saying that you track personal velocity and then sum up the current members of the team to get your burn rate?

Unknown said...

No, you track team velocity. "Personal" velocity shall not be important and can differ form constellation to constellation. If you change/remove/add team members you instead estimate the change in velocity rather than to re-estimate all stories.