8 ms·

The team I worked with tried something similar where we broke down tasks into cards, where each card represented something that should take about a day to compl

The team I worked with tried something similar where we broke down tasks into cards, where each card represented something that should take about a day to complete. Knowing how bad I am at estimating how long tasks take, I was sceptical whether this would work, but it did! After a few months, the team settled down into doing 30 or so (+/- 10% or so) cards per week. This proved very useful for bargaining for more time for feature development and generally being more predictable. The takeaway for me is that good estimation is possible, and that by tracking those numbers you can improve your own estimation skills. Some other reading material that I found useful in this area was Evidence Based Scheduling (http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html) and Software Estimation (http://www.stevemcconnell.com/est.htm http://www.stevemcconnell.com/est.htm)

thesz 15y ago
>The team I worked with tried something similar where we broke down tasks into cards, where each card represented something that should take about a day to complete. This is almost basic probability theory. http://en.wikipedia.org/wiki/Central_limit_theorem http://en.wikipedia.org/wiki/Central_limit_theorem Estimations could be viewed as random samples with some distribution. The total is the sum of individual estimations. The sigma of the total is less than max(single task estimation sigma) * sqrt(number of tasks). 30 estimations with 0.5 day sigma gives us total sigma 0.5 * sqrt(30)=3 and 96% confidence bounds of (30 - 3 * 2)..(30 + 3 * 2) work days. Most of the time you will see 30+-3. ;) Unless you find a task that does not break into one day. Say, with low estimate "tomorrow" and high estimate "half a year". ;)