Agile Zone is brought to you in partnership with:

By day I'm a build and release engineer in London, but by night I'm a normal person! If anyone ever asks me what I do, I usually generarlise and say "I'm in I.T." and then check to see if they've already stopped listening. When I'm not working or blogging I can be found playing rugby or cycling around the countryside on my bike, in an attempt to keep fit and fool myself into thinking I'm still young. James is a DZone MVB and is not an employee of DZone and has posted 54 posts at DZone. You can read more from them at their website. View Full User Profile

It’s Points All the Way Down!

07.25.2013
| 3654 views |
  • submit to reddit
TurtlesAllTheWayDownBertrand 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.


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!

Published at DZone with permission of James Betteley, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Ian Mitchell replied on Thu, 2013/07/25 - 7:40am

Hi James

One thing that can be said for sizing tasks in hours, rather than points, is that it can make the tracking of waste more transparent.

If the team are diverted from the Sprint Backlog (e.g. to work on a support task or emergency) then that task can be made visible on the Scrum board. The actuals, in hours, can then be logged against it. That's arguably a more straightforward exercise than trying to express waste in points. Admittedly it isn't a good example of Scrum in action, because such diversions shouldn't happen in the first place. Given that they do happen though, it can be a rational way to expose the problem.

Also, let's bear in mind that a board should be updated to show the latest understanding of each item's size. If the tasks are expressed in hours then, through the process of regular updating, their values will converge around the actuals. That's great as a representation of the truth, but it turns velocity into a tautology. A team will always end up delivering the hours it has worked. That's why it's a good idea to always estimate stories in relative sizes or points, even if tasks are sized in hours. The estimated points given to backlog items can then be challenged as part of the team's inspect/adapt cycle, and more accurate forecasts can be made.

James Betteley replied on Thu, 2013/07/25 - 8:36am

Hi Ian, thanks for the comment!

I actually use a process of logging interruptions in points as well. It seems to work for us. I've posted some details on how this works for an IT team who are using Scum (I know, right?) http://goo.gl/c4d0fq.

The point you make about the team delivering the hours that it has worked is, for me, a good reason to steer away from hours. If these numbers don't add up, then questions will be asked (the wrong sorts of questions). And these numbers won't add up unless you practice an almost religious devotion to time logging. Hence the use of points, as you mention.

I still don't see that there's any actual advantage of using hours over points. I can see how either one would work, I'm just still not convinced that hours are in any way better.

Ian Mitchell replied on Thu, 2013/07/25 - 9:51am

"The point you make about the team delivering the hours that it has worked is, for me, a good reason to steer away from hours. If these numbers don't add up, then questions will be asked (the wrong sorts of questions)."

Agreed, but a concern about the wrong sort of questions being asked isn't all that great a reason.

Let's remember that when a board is updated, the estimates should show the work remaining, not the work done. At the end of a successful Sprint the numbers should add up to a big fat zero. If it doesn't, then the right questions can be asked about how accurate the initial estimates were.

Unfortunately many teams don't work that way, and ALM tools aren't always configured to this "work remaining" principle. In these cases estimating in hours can indeed lead to the wrong questions being asked, and to developers making a rod for their own backs.

Jim Karabatsos replied on Thu, 2013/07/25 - 9:55pm

What I have done on a number of projects is to just rename hours to points. This has worked really well because the non-delivery members of the project aren't let in on the little secret.

If a task is estimated as 3 hours, we record that as 3 points. New team members are told that estimates are based on dedicated, uninterrupted time to implement the particular item, and no allowance is to be made for the inevitable meetings, client emergencies and numerous other interruptions than we know are going to arise. And of course the estimates become more accurate over time as we know more about the problem domain and the system infrastructure evolves.

This has the advantage of making very clear to the internal group how many productive hours each individual gets in a day or week — it is rarely more than half the available hours, so a velocity of 20 points per person per week is actually not far from the norm. WE know that one point is one productive hour, but we don't share that with the non-delivery team because, like James, that's just not a conversation that you want to have, except with the most enlightened and switched-on users and managers.

Perhaps the biggest benefit of relating a point to some unit of time (we've used anything from 1 point = 1 day to 1 point = 0.5 hours before settling on 1 point = 1 hour) is that all the estimators have a common understanding on what a point represents. Even when we didn't formally do this, I found that estimators would say something like "Less than 1/2 day is one point, 1-2 days is 3 points and anything more is 6 points" when working with a new team member. People need that conversion factor because when they are looking at a story to estimate it, they are actually thinking in terms of the time required to implement it.

The potential down-side to this approach is that estimators unconsciously build in the velocity into the estimates, rather than letting the velocity fall out in the wash. For example, they might say to themselves "this is half a day's work, but I know it'll take a full day to get it done given all the other things going on" and estimate the task at 8 points instead of 4 (because they're thinking "hours" instead of "points"). This then devolves into traditional, elapsed-time based estimation which (in my experience) is not a good thing, so you need to keep on top of this and reinforce the importance of estimating based on dedicated, uninterrupted time with no task switching.

The other important thing is that we always remember the initial estimate. We don't expect it to still be valid, but it is important to know what happens to initial estimates over time. If we find that, in general, every 100 points of initial estimates become 130 points of later estimates, and a per-person velocity of 20 points per week is what the team is actually delivering, these figures allow us to make realistic assessments of the backlog of stories that only have initial estimates. We know that (in the above example) there is likely to be 30% more points in the backlog than the initial estimates suggest, and that the time required to complete that work is therefore likely to be [the backlog estimate] * 1.3 / 20 / [number of developers] weeks (I think I did that calculation right — you get the idea).

— Jim Karabatsos
jimako.com

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.