Menu
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?
873
Story points should NOT be explicitly linked to man-days of effort, as they are meant to be a purely relative estimate i.e. the team believes that a Story estimated as 8 points will be about four times as much work as a Story estimated as 2 points.
Hours give worse estimates, introduce large amounts of waste into the system, handicap the Product Owner's release planning, and confuse the team about what process improvements really worked. Many people who have managed projects with hours have a hard time understanding why story points are better.
Tasks, but not User Stories, are estimated in hours. Estimating Tasks using hours makes sense because Tasks are shorter than User Stories and Tasks are not estimated until the Development Team is ready to begin working on the Task.
Each Story Point represents a normal distribution of time. For example,1 Story Point could represent a range of 4–12 hours, 2 Story Points 10–20 hours, and so on.
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).
151
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
