On Mar 23, 1:26 pm, "Chris Nelson" <[email protected]> wrote: > http://trac-hacks.org/wiki/TimeEstimationUserManualsays: > > Fields: > ... > * Estimated Hours a field that contains the estimated amount of work > > We've been using this for months and have always determined the amount of > effort remaining as (estimate-actual). When we find that we were wrong in > our initial estimate, we increase it. Looking in the database for increased > estimates can show us how bad we are at estimating. As can tracking > actual/estimate (<1 is ahead of schedule, <1 behind). > > But now we're looking for burndown chart and both the EstimationToolsPlugin > and the ScrumBurndownPlugin treat Estimated hours as *remaining hours*. I > think that they should be graphing estimate-actual but maybe I'm missing > something. > > Chris
I had this same question. There's a problem with that. EstimatedHours is just that, and estimate. total hours are not bounded by Estimated hours, and when Estimated -Actual = 0 doesn't mean there is no work left. We personally don't like the estimates to be modified. usually there is at most one modification, since we put a SWAG on the tickets when a dev accepts it, sometimes the SWAG is wildly off, however, the intent is that the developer takes a little time to do a reasonable estimation. Our solution was to allow the "hours" remaining to float a little high, in that it uses estimated hours. So if a ticket has 15 hours estimated, and 14 hours are completed, even it there truly is only 1 hour remaining, it reports as 15 remaining. It really encourages us to make really small tasks as tickets. we use a feature-branch/ feature ticket model, so the SWAG for the feature remains from the initial. The "best" solution, I suppose, is to use Estimated hours, total hours, AND hours remaining. and do your burndown on hours remaining. you of course start with estimated = total remaining, and total (or actual)=0. however, what a pain. you have to add hours, AND adjust the remaining estimate (or not). but then you can increase remaining. preserving the intial estimate, and the actual, for posthumous analysis on individuals estimation tendencies. In our model, the Lead puts in the Swag on the features (say, 150 man hours for "Feature - Implement Menu System"), the Developer creates a bunch of finite blocking tickets(like, create service menu, add icons to service menu, create file menu...), usually as he goes, and we end up with 2 levels of "estimates" metrics. Our high level, long term Wild A%% guess we gave a year ago, and a more realistic total once we get around to actually working on the feature (and adjust the schedule accordingly) . We then end up with actual to see how bad those are off. The downside, is that our daily, or even weekly snapshot can be skewed high, and we are encouraging the "management" types to look at our current status pages and the burndown tools for information, rather than ask us for a gazillion emails and meetings. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
