Re:An epic treatise on scheduling, bug tracking, and triage
by markphip on Thursday December 14, 2017 @07:11PM
(#15928643)
Thanks and interesting. If you have written up your full system anywhere I would be interested to read more.
Re:An epic treatise on scheduling, bug tracking, and triage
by lliamander on Tuesday December 19, 2017 @01:59PM
(#15962965)
In terms of mapping story points to time ranges, here's the full list:
1 point -> 2-4 hours
2 points -> 4-8 hours (1 day or less)
3 points -> 1-2 days
5 points -> 3-5 days (up to one week)
8 points -> 5-9 days (up to one two-week sprint[0])
13 points -> 2-3 weeks (1-1.5 sprints)
20 points -> 3-4 weeks (up to two sprints)
40 points -> 1-2 months
Anything beyond 40 needs to be aggressively analyzed broken down into steps, even if those steps are not deliverable features per se.
[0]For a two-week sprint, you have to account for at least one day each sprint for demos, retrospective, and planning. Thus, you have at most 9 days for implementation and testing.
EDIT: Fixed formatting.
Rather, I like to use a discrete list of story point values as scalar value that represents a probability distribution for how long the task might take. As the story point gets bigger, not only does the mean time get bigger, but the variance grows as well.
For example, a 1 is 2-4 hours, but a 13 is 2-3 weeks, and a 40 is 1-2 months. The idea is that not only do more complex tasks take more time, but the precision of our estimates goes down.
This makes engineers happy because they get to be more honest about estimates, and it makes managers happy because they only have to deal with one number.
[1] Unit-less measures might be easier in an environment that is more concerned with true productivity than with deadlines, but that is not most environments.