Bertrand Russell once gave a lecture on astronomy, and how the earth rotates around the sun, and how the solar system is part of a vast galaxy, etc and so forth… At one point he was interrupted by an old lady, or so the story goes, who said “What you’re saying is rubbish, the world is a flat plate resting on the back of a giant turtle”. When Bertrand Russell questioned her as to what’s below the turtle, she replied “Another turtle”. Bertrand persisted with “And what’s below that turtle then?” to which the lady replied “It’s no use – it’s turtles all the way down!”
I was reminded of this story recently when I was in discussion with a colleague about sprint planning. My colleague was explaining to me that they use story points for sizing and estimating stories, but they then break their sprint stories down into smaller tasks and use hours to estimate these tasks, rather than continue to use points.
I had never come across this particular practice before. Of course, I’ve seen teams who do everything in hours, I’ve just never worked with a team which used both points and hours. I’ve always worked in points for story sizing, and when the stories need breaking down, I would break them down into smaller points: It’s points all the way down! I’ve never had any problems with this approach, so I was curious as to the advantage of switching to hours.
My first port of call, as always, was Google. When that came up empty I turned to Twitter, and got a friendly response from none other than Mike Cohn.
@jamesbetteley Sure see http://t.co/Baa6RXPMQ1 and the iteration planning chapter of http://t.co/HYuMlUKv0q
— Mike Cohn (@mikewcohn) July 19, 2013
Now, I never thought I’d find myself disagreeing with Mike Cohn, indeed his book “Succeeding With Agile” has been something of a bible for me for the last few years, but on this issue I am still not convinced.
Mike has written a really interesting blog post on why he uses hours rather than story points for sprint planning (you can find it here). One of his reasons is because he feels hours are better short-term measure than points. In some circumstances I would agree with him (perhaps if your stories are MASSIVE, and you need to break them down into much smaller tasks), but in my experience it doesn’t generally appear to hold true. I use points for both stories and tasks – the only difference is that when we get around to task estimation & sizing, we expect to be a little more accurate than when we estimated the stories in the product backlog. Quite often we will take a story of say 5 points, and break that down into two 3 point tasks. So 3 + 3 doesn’t add up to 5. Who cares? the 5 was an estimate anyway, and I always push to make everyone understand that estimates are just guesses, and the further out we make the estimate, the more approximate it’s going to be. By the time we get around to doing our sprint planning i expect us to take a much deeper look into these stories, and benefit from additional analysis, so naturally I expect our estimate to change.
I usually do everything I can to steer away from hours, because it can often be too confusing for people outside of the team to understand why the total hours don’t add up to the total available resource hours. I’d rather just not have this conversation sometimes! Also, after explaining to everyone the key benefits and purpose of using points, I can imagine they’d be confused as to why we were suddenly ditching all the advantages of points, and switching back to hours for the sprint planning. By the way, I’ve covered the reason why we use points over hours in my previous blog post here.
Anyway, I just thought I’d write this post to show that both approaches are common, and I guess it’s just a matter of “whatever works best for you”. But I’m still not convinced with the whole hours thing!
This is an area that I’ve been wondering about recently. I’m also reminded of a recent article (I don’t remember who wrote it) which suggested trying very hard to stay away from the word “estimation” in story sizing, to prevent leaking a notion of time into it. In agile, we give stories point values that reflect their “size” and not how long we think it will take to implement it. When you follow through with this idea, it seems like you might have trouble maintaining a consistent sprint velocity because no matter how you “size” things, you still have to implement those stories in an actual period of time, being a sprint. As we’re giving stories a “size” value that might be independent of particular issues in its required implementation that will take more or less time than other stories, we will obviously end up fitting a variable number of story points into our sprint.
* During your ministry role, what was the most dfcuifilt adjustment you’ve had to make?Learning to lead without being a leadership position. Changing an organization from within the ranks of the working instead of the leading.What was the situation?A peer of mine was promoted and morale was really low. There were a great number of dfcuifilties in how she was leading.Why was it a dfcuifilt adjustment?Hard to take order from someone that didn’t do the actions or exemplify the qualities of what she was expecting of us. Also hard to take orders from someone viewed as a peer.What did you do?The opposite of what I wanted to do. I prayed that God would bless her, and taught her everything that God was teaching me about management and leadership.What happened as a result of your actions?We have started to change our organization. Our team has grown closer. We are all more emotional literate, and having deep fulling conversations.
Hi David, very interesting comment. The thing with velocities is that they’re still just an estimate! The only difference is that they’re based on empirical evidence (i.e. previous sprints data). The problem with this is that we’re not doing the previous sprint, we’re doing a new one, and since software development is not a simple, uniform task (software development has variable effort because our tasks are generally not uniform) the practice of using a previous sprint’s data as a guide is fundamentally flawed.
However, in reality, estimates do somehow work, and velocity is a useful metric. Perhaps our tasks have just enough uniformity or similarity with other tasks that estimation still roughly works. I don’t know. The trouble is, the business always wants estimates, it’s in their DNA! I tend to try and make it very clear that estimates and velocities are still just a best-guess, but they’re still better than any other form of guesswork.
As for the hours thing – given how approximate our guesses are, I still don’t quite understand the advantage of using them.