3416RE: [scrumdevelopment] Re: SCRUM & Change / Defect Management
- May 4, 2004
MessageSometimes keeping actuals is not a "choice", is a mandatory:mb-----Original Message-----> > I'm curious why your developers are fine with daily updating of
From: Steve Bate [mailto:steve@...]
Sent: Tuesday, May 04, 2004 9:20 AM
Subject: RE: [scrumdevelopment] Re: SCRUM & Change / Defect Management
> > their remaining time estimates but they fight tracking actual time
> > (again, for the purpose of calculating remaining time in the XPlanner
> > context).
> The issue is that the effort expended has no definitive relationship with
> the remaining estimate to complete (ETC), the number can even be negative,
> i.e. after a day of effort the task ETC may have increased.
Right, most teams use XPlanner to calculate ETC based on the task effort
estimate and the actual time worked (ETC = estimate - actual). However,
ETC in XPlanner is always equal or greater than zero. If the actual would
exceed the estimated effort, a new (larger) estimate is requested. A task
can be reestimated at any time. After reestimation, the ETC might be larger
> As we are
> focused on the planning aspect of the process (will we complete
> the selected work this Sprint?) the only thing we need to track is ETC,
> not actuals. Psychologically it is easier to re-estimate a larger ETC at
> the end of a days work than explicitly record the fact that your estimate
> was wrong or that you haven't worked hard/smart enough.
I wondered if that last issue might be one of the sources of resistance
to recording actuals.
Our team uses ETC to track intra-iteration (we're an XP team) status. We
generally use previous actuals and estimation accuracy during our planning
activities although a task that's been significantly reestimated during
an iteration might trigger a related discussion in the standup meeting.
For example, we learned that we tend to underestimate web development
stories and the team determined it was because the functional tests were
difficult to write. This motivated us to improve our web testing
framework. Other stories would tend to run over because they depended
on obtaining business information from our parent company and we
were often passed to several intermediate people while obtaining the
data. Once we noticed the trend of those stories exceeded estimates
and determined why, we worked with the parent company to create more
efficient ways to obtain the data we needed. I believe that having
hard evidence of the impact of these inefficiencies decreases the
response time in addressing them.
Ken Schwaber discussed the pros and cons of tracking actuals in
I agree with Ken that it's not a silver bullet. Still, we have found
the extra feedback to be useful.
> > Eventually I'd like to extend XPlanner so that the planning and
> > tracking can be configured to handle a wide range of XP process
> > variants. This (and a Scrum-specific web skin) should also make
> > it an even better fit for Scrum teams.
> Cool idea. Once I've finished my house move I would like to help (Though
> that date is moving out two days per calendar day!)
:) I completely understand. I'm constantly doing a time balancing act
between my myriad activities and working on XPlanner. Although the Scrum
skin could be created immediately, the advanced configurability will require
some significant internal refactoring over several releases. OTOH, even with
the current implementation, the skin could present a view that only tracks
ETC. Like I said in a previous message, I've never used XPlanner in this way
but there shouldn't be any major problems. If there are small problems,
I'd be happy to make those changes to better support Scrum teams.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
- << Previous post in topic Next post in topic >>