Scrum and Story Points - why aren't perfect person days perfect?

Question

I’m used to thinking about temporary estimates at the suggestion of Joel Spolsky - that if the planned item takes more than 16 hours, it should be divided into smaller tasks. Now I implement Scrum in my team along with Story Points. It seems to me that a good unit for a Source is an ideal man-hour, not a man-day. If I used the days, most of my questions would have ratings of 1/2 or 1.

Do you have any ideas why the use of ideal person days is most often mentioned in Scrum literature?

Answer 1

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

This phrase sounds really, really strange, and not true. Where did you read that there is a correlation between the points of history and the ideal man-day? The ideal person days may have been used in the early days of Scrum, but for me, Story Points (SPs) are another matter ...

Story Points is a way to quantify the relative effort associated with a particular product backlog (PBI), which consists of several tasks. Some teams use the numerical size (for example, a scale from 1 to 10) to estimate the “size” of the PBI, others use the sizes of t-shirts (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 SPs don't have units?

If I used days, most of my problems would have ratings of 1/2 or 1.

So what? This would mean that you have small PBIs, which is nice (at least not for the most important). But do not forget that theoretically there are two levels of assessment in Scrum: the level of lag of a product in points and the level of lag of Sprint in hours. As I mentioned in the previous paragraph, the PBI consists of tasks, and they should be divided into tasks in the second part of the Sprint planning meeting. Then the tasks are evaluated in hours, and the 16h rule applies: the task should not exceed 16 hours. If so, it is too large and should be divided into smaller tasks (because we value large things too poorly).

Do you have any ideas why the use of ideal person days is most often mentioned in Scrum literature?

In any case, it is out of date. The situation may change in the future, but the current consensus should be measured in units without loss. Points are completely separate from any unit of time, and this is to intentionally avoid any comparison with a unit of the real world, labor productivity should be measured using speed (the number of points that a team can achieve in one iteration).

Answer 2

The hourly grade is too fine. He will also strive for more micro-management, which is somewhat contrary to flexible principles.

If I have four tasks, each of which is evaluated in half a day, I can be sure that in two days I will have a good pen.

But 16 one-hour assignments? I have much less confidence in what is being done over the same period of time, since any of the tasks is subject to too much variability.

Answer 3

The purpose of story points and evaluations of the game as a whole is to effectively judge speed by several sprints.

Thus, it doesn’t really matter which units are used for evaluation if everyone in the team is evaluated equally and the same units are used in each evaluation session.

It is also very important to make sure that different teams are not trying to match their story points. What I consider to be the plot will not necessarily be what you have.

So - I can’t give an answer, except "go with what seems appropriate."

Answer 4

• Googling for "scrum ideal man day" gives 6,500 results, and "scrum ideal man day" gives 10,000 results. Not that much of a difference. I did not notice a bias towards literature.

• Nothing really valuable is rarely done in less than half a day (minimum duration of a task) or even weeks (minimum duration of a sprint).

• Watch rating can give a false sense of accuracy. Despite the fact that 5 ideal hours of a person are accurate, he is probably no more accurate than 0.5 ideal human days.

• Ideal units of a person also convey the concept of matching real worlds with similar units, such as hours or days. Display is rarely simple. This is why many agilists prefer single story points as a measure of the size of the task. The team’s speed metric, and then matching from abstract size estimates to real-time.

Answer 5

If you follow the proper Agile rules, with full unit test coverage and a red-green-refactor loop, there are quite a few meaningful tasks that take less than half a day. In addition, the use of days counteracts the tendency of developers to underestimate the time required for a task. And, of course, it’s better to overestimate time and overload than underestimate and underestimate.

Answer 6

I don’t know, but I’m ready to guess that this is because the “standard” scrum length is 30 days. If you plan to work in blocks of 30 days, you will need coarser units of measurement than if you had a sprint of 1 or 2 weeks in length .

Most scrum implementations I have seen have a spring length of 1 or 2 weeks, so counting the “ideal hours” is more useful since the relative sizes of the tasks are smaller.

As for the relative measure of effort and assuming that you are using scrum for software development, I would count the number of separate source codes that you have committed , you could do if you developed each task and use it as a measure.