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).

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.

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".

• 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.

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.

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.