views:

693

answers:

6

I am used to thinking about time estimates in the way suggested by Joel Spolsky - that if a scheduled item takes more than 16 hours, it should be divided into smaller tasks. Now, I am implementing Scrum in my team together with Story Points based estimations. It seems to me that a good unit for a Story Point would be ideal man-hour, not man-day. If I used days, most of my issues would have estimates 1/2 or 1.

Do you have any idea, why the use of ideal man-days is mentioned most often in the Scrum literature?

A: 

If you're following proper Agile practices, with full unit test coverage and the red-green-refactor cycle, there are a vanishingly small number of meaningful tasks which will take less than half a day. Also, using days counteracts the developers' tendency to underestimate the time required for a task. And of course, it's better to over-estimate times and over-deliver than to under-estimate and under-deliver.

Coder 42
except that sometimes you may not get the go-ahead for a task/ project if you overestimate. Remember it's easier to ask for forgiveness than permission ;-)
Phil Nash
+1  A: 
  • Googling for "scrum ideal man hour" gives 6500 results while "scrum ideal man day" gives 10000 results. Not that big a difference. I haven't noticed a bias towards either in the literature.

  • Nothing really valuable rarely gets done in less than half a day (min. task duration) or even a week (min. sprint duration).

  • Estimating in hours can give a false sense of accuracy. Even though 5 ideal man hours is precise, it's probably not any more accurate than 0.5 ideal man days.

  • Ideal man units also convey the notion of mapping to real world similar units such as hours or days. The mapping is rarely straightforward. That's why many agilists prefer unitless story points as a task size measure. Team velocity metric then does the mapping from abstract size estimates to real world time.

laalto
sometimes 5 man hours is no more accurate than 0.5 man weeks!
Phil Nash
+2  A: 

It seems to me that a good unit for a Story Point would be ideal man-hour, not man-day.

This phrase sounds really, really strange, and not true. Where did you read that there is a correlation between Story Points and ideal man-day? Ideal man-days were maybe used in the early days of Scrum but, to me, Story Points (SPs) are a different thing...

Story Points are a way to to quantify the relative effort associated with a particular Product Backlog Item (PBI) which is composed of multiple tasks. Some teams use numeric sizing (i.e. a scale of 1 to 10) to estimate the "size" of a PBI, others use t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), some use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc). And by the way, did you notice that SP are unit-less?

If I used days, most of my issues would have estimates 1/2 or 1.

So what? That would just mean that you have small PBIs, which is not a bad thing (at least not for the most important one). But don't forget that there are theoretically two level of estimation in Scrum: the Product Backlog level, in points, and the Sprint Backlog level, in hours. As I mentioned in the previous paragraph, PBI are composed of tasks and they should be split into tasks during the second part of the Sprint Planning Meeting. And tasks are then estimated in hours and the 16h rule applies here: a task should not exceed 16h. If it does, it is too big and should be split into smaller tasks (because we are too bad at estimating big things).

Do you have any idea, why the use of ideal man-days is mentioned most often in the Scrum literature?

This is outdated anyway. Things might change in the future but the current consensus is to estimate in unit-less points. Points are entirely decorrelated from any time unit and this is intentional to avoid any mapping with real world unit, work capacity should be measured with the velocity (the amount of points a team can achieve in one iteration).

Pascal Thivent
I didn't know there are two levels of estimation. This clarifies a lot for me. Thanks. I am actually more interested in the second, fine-grained level, because I want to estimate, how much we can do in the next sprint.
Michal Czardybon
Glad it was helpful. Regarding the end of your comment, *"how much we can do in the next sprint"*, you should use the "yesterday's weather" method: today's weather will be the same as yesterday. So the answer is likely the same amount (or very similar) as in the previous Sprint. This is one of the point of tracking velocity. Of course, this works only if you already have historical data, i.e. not for the first sprint.
Pascal Thivent
A: 

Estimating at the hour level is too fine-grained. It also will tend to drive to over micro-management, which is somewhat antithetical to agile principles.

If I have four tasks, each estimated at a half day, I can be relatively confident that in two days I'll have a good handle on them.

But 16 1-hour tasks? I have much less confidence in those being done in the same period of time, as any one of the tasks is subject to way too much variability.

kyoryu
When you are new at estimating, this is simply wrong. Only start estimating in days when you can reliably show sufficient precision in hours.
Stephan Eggermont
I was really suggesting more along the lines of 4-8 hour tasks, rather than tasks taking multiple days. I've just seen too much variability in most tasks at the 1 hour level. Anything over 8 hours is asking for trouble, especially at first. However, I completely understand your point of view, and I'd agree that 1 hour tasks are far better than 1 week tasks.
kyoryu
Or, to put it more succinctly, I don't mind tasks at the day level, but think the hour level is too fine-grained. However, I think tasks at the hour*s* level are fine, and tasks at the day*s* level are too coarse. I think I was arguing the singular version of the nouns, while you were arguing the plurals :)
kyoryu
+1  A: 

The purpose of story points and the estimating game in general is to effectively judge velocity over several sprints.

So it doesn't actually matter what units are used to estimate, so long as everyone on the team estimates in the same way, and the same units are used at each estimation session.

It's also very important to make sure that different teams don't try to correlate their story points. What I think of as a story point won't necessarily be what yours is.

So - I can't provide an answer other than "go with what seems appropriate".

Jeremy McGee
A: 

I don't know but I'm prepared to speculate that this is because the "standard" scrum length is 30 days. If you're planning to do work in blocks of 30 days then you're going to need coarser units of measurement than if you had a sprint length of 1 or 2 weeks.

Most of the scrum implementations I've seen have spring lengths of 1 or 2 weeks - so counting "ideal hours" is more useful because the relative task sizes are smaller.

As far as a relative measure of effort is concerned and assuming you're using scrum to develop software I'd count the number of separate source code commits you could make if you developed each task cleanly and use that as a measure.

cartoonfox
This 30 days sprint length was true in the early Scrum days in the 90's but is totally outdated and not really used anymore. The current trend seems to be 2 weeks but this may vary from one team to the other, there is actually no "standard" Sprint length.
Pascal Thivent
I remember quite a long rant from Ken Schwaber in 2003/2004 about people fiddling with scrum sprint lengths - before understanding how it works. He kept telling people to implement 30 day lengths. In XP, we typically do 1 or 2 week iterations - which is probably how people get around to that - but XPers typically don't estimate in ideal days (or even hours) for that matter...
cartoonfox
Interesting. I really thought this was older than 2003 (at least this is what I remember from my discussion with Jeff Sutherland). But I admit I didn't check the archives of the scrumdevelopment list. Anyhow, this "standard" is now clearly outdated and isn't a standard anymore. Actually, I like the XP point of view about iteration length: "how much work are your ready to throw away" :)
Pascal Thivent
You won't find the rant I'm referring to on any mailing list - it was in his talk at XPDay2 http://xpday2.xpday.org/programme.php
cartoonfox