top | item 21073074

(no title)

crumpets | 6 years ago

>After doing this for a while, you can use these relative effort estimates to project completion dates for new projects.

This doesn't work. The problem is that you get periods where the work is relatively easy overall so 5 points ends up being tasks that take 2 days. Then you pick up new difficult features and estimate everything relative to all of the new hard tasks and you end up with 5 points meaning 5 days.

Sure you can gauge relative difficulty of tasks between each other, but in a regular developer's day-to-day life the range should really be 1-100 or so rather than making stuff fit into 12 points or less.

discuss

order

alexhutcheson|6 years ago

1. Keep your baseline tasks you're comparing against consistent for as long as you can (as long as the team remembers them and agrees on the effort they required). Don't use a task from week 2 to estimate week 3, etc.

2. Don't use a short time interval or moving average to determine your points->time mapping. You're looking for the long-run average mapping, not a specific estimate for this developer today.

amatecha|6 years ago

+1 , this guy knows what's up. Relative estimates work really well, from my experience!

yesbabyyes|6 years ago

I think it's common to use the Fibonacci sequence as the difference between each valid weight increases pretty fast.

lifeisstillgood|6 years ago

i like the 1-100 idea. so often the same points come back (a world of 1 and 3 pointers) but really have we broken that down?

I think we should always have reference tasks in front of us -