Curious Cat Management Improvement Blog : Agile Story Point Estimation

Source: Curious Cat Management Improvement Blog

In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).

I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.

Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).

Large stories just can hide huge variation in what is really required once getting into implementing it.

The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).

Related: Assigning Story Points to Bug Fixes – Mistake Proofing the Deployment of Software Code – Checklists in Software Development

These thoughts were prompted by: Story Points Considered Harmful – Or why the future of estimation is really in our past…

As with all techniques this one comes with a disclaimer: you may not see the same effects that I report in this post. That’s fine. If that is the case please share the data you have with me and I’m happy to look at it.
My aim with this post is to demystify the estimation in Agile projects. The fact is: the data we have available (see above) does not allow us to accept any of the claims by Mike Cohn regarding the use of Story Points as a valid/useful estimation technique, therefore you are better off using a much simpler technique! Let me know if you find an even simpler one!

Oh, and by the way: stop wasting time trying to estimate a never ending Backlog. There’s no evidence that that will help you predict the future any better than just counting the number of stories “Done”!

This long post has good points in it. And I may be missing some of what is being said. But I find story point estimation to be worthwhile.

I can imagine assuming all stories are the same size works decently well. That goes along with the notion that we found which was the importance of keeping stories small. When we got into some trouble it was with stories that should have been further broken down into several stories (so we focused on doing that). Sometimes that required a spike to understand what the issues were.

I think it works well to have stories that are “too big” sitting on the backlog, but as they are approaching being worked on then take a look at them, define them a bit better and make sure they are not too big.

We wouldn’t waste much time at all on estimating a huge story. Just note that is a huge story and it needs to be looked at when/if we get close to doing it. If it was critical/required we might spend 10 minutes getting a few highlights for what key points (If we did x any y it would be way easier, lets see if that is ok. Maybe z would make this work fairly easily we can spike that and see…).