4 ms·
Thanks for the response. I appreciate it. Here is my take away from this: that's overly complicated. We all have a finite amount of time. Most of use allocate
by movedx 6y ago
Thanks for the response. I appreciate it.
Here is my take away from this: that's overly complicated.
We all have a finite amount of time. Most of use allocate 8 hours of the day to work. With that in mind, and given we have a team of 5, we have 5 * 5 * 8 - 200 - hours of (technical) labour per week.
Based on experience we all know that what we actually have in terms of time applied to problems is closer to 5 hours. Let's say we agree that's the truth. So we now have 5 * 5 * 6 or 150 hours of skilled, technical labour per week.
Taking a unit of work, a problem, and assigning it to someone creates the context for determining how long it will take to do. Whether or not Janes can work faster than Bon has nothing to do with it, in my opinion.
Bob can solve the problem in two days, or 16 hours, based on his experience and skill. Jane can do it in 10 hours. So give the job to Jane if it's urgent, or to Bob if you can wait.
You know what exactly to expect based off of this simple process: you've lost Bob for 16 hours.
I feel it doesn't need to be any more complicated than this.
- beckingz 6y agoThe points help abstract away the task estimates from actual time worked. If you estimate that you will do 40 hours of tasks and only complete 30 "hours" of tasks because one of them turns out to be more complicated than estimated, it's hard to explain that to most people. It's easier to say you did 30/40 points because <task> was more work than anticipated. The separation of points and hours worked also helps a little bit with some perception issues when comparing developers, as human emotions tend to get involved if people feel accused of being inefficient or working less. But you are right that it does not have to be more complicated than estimating hours.
- movedx 6y agoThis actually makes sense. Thank you.