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.
发布评论
评论（6）
这句话听起来真的非常非常奇怪，而且不真实。您在哪里读到故事点与理想工作日之间存在相关性？理想的人日可能在 Scrum 的早期使用，但对我来说，故事点 (SP) 是另一回事......
故事点是一种量化与以下相关的相对工作量的方法由多个任务组成的特定产品待办事项 (PBI)。有些团队使用数字尺码（即 1 到 10 的比例）来估计 PBI 的“尺寸”，其他团队使用 T 恤尺寸（XS、S、M、L、XL、XXL、XXXL），有些团队使用斐波那契数列序列（1、2、3、5、8、13、21、34 等）。顺便问一下，您是否注意到 SP 是无单位的？
那又怎样呢？这仅意味着您的 PBI 较小，这并不是一件坏事（至少对于最重要的 PBI 而言不是坏事）。但不要忘记，理论上 Scrum 中有两个估算级别：产品待办事项级别（以点为单位）和 Sprint 待办事项级别（以小时为单位）。正如我在上一段中提到的，PBI 由任务组成，应该在 Sprint 计划会议的第二部分将它们拆分为任务。然后，任务以小时为单位进行估算，并且此处适用 16 小时规则：任务不应超过 16 小时。如果确实如此，那就太大了，应该分成更小的任务（因为我们太不擅长估计大事情）。
无论如何，这已经过时了。未来情况可能会发生变化，但目前的共识是用无单位点进行估计。点与任何时间单位完全不相关，这是为了避免与现实世界单位的任何映射，工作能力应该用速度来衡量（团队在一次迭代中可以实现的点数量）。
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?
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).
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).
按小时级别进行估算过于细粒度。它还会倾向于过度微观管理，这在某种程度上与敏捷原则相反。
如果我有四项任务，每项估计需要半天时间，那么我可以相对有信心在两天内很好地处理它们。
但是 16 个 1 小时任务？我对在同一时间段内完成的那些任务的信心要低得多，因为任何一项任务都会受到太大的变化。
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".
谷歌搜索“scrum Ideal man hour”给出 6500 个结果，而“scrum Ideal man day”给出 10000 个结果。差别没那么大。我没有注意到文献中对这两者有偏见。
没有什么真正有价值的事情很少能在不到半天（最短任务持续时间）甚至一周（最短冲刺持续时间）内完成。
没有什么真正有价值
以小时为单位进行估算可能会给人带来错误的准确性感。尽管 5 个理想工时是精确的，但它可能并不比 0.5 个理想工时更准确。
理想的人单位还传达了映射到现实世界类似单位（例如小时或天）的概念。映射很少是简单的。这就是为什么许多敏捷专家更喜欢使用无单位故事点作为任务规模衡量标准。然后，团队速度指标将抽象规模估计映射到现实世界时间。
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.
我不知道，但我准备推测这是因为“标准”scrum 长度是 30 天。如果您计划以 30 天为单位进行工作，那么您将需要比 1 或 2 周的冲刺长度更粗略的测量单位。
我见过的大多数 Scrum 实现的弹簧长度都是 1 或 2 周 - 因此计算“理想时间”更有用，因为相对任务规模较小。
就相对而言关注工作量的衡量标准，假设您使用 scrum 来开发软件，我会计算您可以干净地开发每个任务并将其用作单独的源代码提交的数量一种措施。
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.