I'd build the differentiating vars into the sprint item data.
That said, the best ROI is from meeting with your "reports" weekly, in the ways that Rands describes. Help them become tuned in and turned on (as we said a few generations back) and everyone wins.
>>As my HS chem teacher like to remind us, "to get the right answer, you have to ask the right question."
>>
>>Various questions in this thread seem to be asked. So each answer is likely correct for the implicit question asked.
>>
>>My question would be (in its crudest form): what percentage of an estimate do I have to add (or implicitly subtract) from an initial estimate to get an estimate based on past performance? Note that I am specifically not interested in "rating" the developer for a given sprint (the variance for a single data point is by definition unknown).
>>
>>So my answer would be:
>>
>>adjustment_percent = (all_actuals - all_estimates) / all_estimates
>>
>>If my numbers are:
>>
>>
>>estimate actual
>>12 2
>>33.5 65
>>
>>Totals: 45.5 67
>>adjustment_percent: 47
>>
>>
>>
>>Then I would average the adjustment _percents. Note that with n large enough, a variance could be found for this number, leading to an estimate of margin of error.
>>
>>Now, this gets interesting. If I have n large enough, I can look for differentiating factors, such as "big" vs "small", or "greenfield" vs "rewrite", dev platform, etc. With enough data for a single developer I could use differential Multiple Regression analysis to determine the amount of variance my suspect factors contribute. I could also use the dataset from all developers to see how much variance is contributed by which of the same factors and also by which developers. Etc.
>
>My take is in similar direction, but on purpose I stayed within linear regression. Yes you probably could explain more of the residual variance if more dimensions are covered (type of task, like GUI, biz or DB layer for each dev) but the additional overhead for task classification and estimation will eat up the ROI ;-)
