>
> I'm curious why your developers are fine with daily updating of
> 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. 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.

>
> > Hm. Is there any way to hack XPlanner in the meantime to get it to work
> > the way you (and I) would expect it to work?
>
> See the messages referenced above.

We are not using Xplanner yet but plan to simply update the ETC each day, as
described on the Xplanner site. I would just like it to be as simple as
updating the actuals (especially in the IDE plug-ins). Even better would be
to be able to turn off the actuals completely.

>
> 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!)

Cheers

Tom

--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender.
--------------------------------------------------------------------------------

Steve Bate

... Hi Tom, Right, most teams use XPlanner to calculate ETC based on the task effort estimate and the actual time worked (ETC = estimate - actual). However,

Message 2 of 23
, May 4, 2004

0 Attachment

> > I'm curious why your developers are fine with daily updating of
> > 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.

Hi Tom,

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
or smaller.

> 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.

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.

> > I'm curious why your developers
are fine with daily updating of> > 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.

Hi Tom,

Right, most teams use XPlanner
to calculate ETC based on the task effortestimate and the actual time
worked (ETC = estimate - actual). However,ETC in XPlanner is always equal
or greater than zero. If the actual wouldexceed the estimated effort, a
new (larger) estimate is requested. A taskcan be reestimated at any time.
After reestimation, the ETC might be largeror smaller.

> 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
resistanceto recording actuals.

Our team uses ETC to track
intra-iteration (we're an XP team) status. Wegenerally use previous
actuals and estimation accuracy during our planningactivities although a
task that's been significantly reestimated duringan iteration might
trigger a related discussion in the standup meeting.

For example, we
learned that we tend to underestimate web developmentstories and the team
determined it was because the functional tests weredifficult to write.
This motivated us to improve our web testingframework. Other stories would
tend to run over because they dependedon obtaining business information
from our parent company and wewere often passed to several intermediate
people while obtaining thedata. Once we noticed the trend of those stories
exceeded estimatesand determined why, we worked with the parent company to
create moreefficient ways to obtain the data we needed. I believe that
havinghard evidence of the impact of these inefficiencies decreases
theresponse time in addressing them.

I
agree with Ken that it's not a silver bullet. Still, we have foundthe
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 actbetween my myriad activities and
working on XPlanner. Although the Scrumskin could be created immediately,
the advanced configurability will requiresome significant internal
refactoring over several releases. OTOH, even withthe current
implementation, the skin could present a view that only tracksETC. Like I
said in a previous message, I've never used XPlanner in this waybut 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.

Agreed. For many of us, time reporting is mandated - usually not for the functioning of the team itself, but for management. I m of two minds as to whether

Message 4 of 23
, May 4, 2004

0 Attachment

Agreed. For many of us, time reporting is mandated - usually not for
the functioning of the team itself, but for management.

I'm of two minds as to whether it's a bad thing to record time spent
and time remaining in the same tool...

In Scrum, I work hard to convince developers that I REALLY REALLY
mean it, when I say "upate your estimates to reflect *real* time
remaining". They have trouble believing that I DO want them to
increase estimates when needed. One thing I'm always saying (to get
them to lose the old habit of under-estimating) is "I don't care
about your actuals". I never come back to them about actuals, and
eventually they believe me...

If I ask them to put "time spent" into the same tool as "time
remaining", it /looks/ like I might be tracking their actuals vs
estimates... will this make them hedge on the "time remaining"
figures?

And on the other hand, it's more convenient than having to open 2
tools...
???

I think the point that Tom is making is that it makes more
sense to most developers (myself, anyway) to estimate a new
Estimated Time to Completion than to update ETC by attempting
to re-estimate the total task.

> Joe and Brad,
>
>
> 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.
>

Steve,

I've appreciated your interacting on this.
I see now, why you might want to track the
original estimate for planning purposes at
the next sprint meeting.

It turns out that it won't matter for me
for a while. My head IT guy doens't want to
install Apache on any of our servers.
I'm not sure what that's about, and he has
somewhat avoided the question. But I don't
want to irk him over such a small thing.
So look like we'll go a different direction.

We've got Deb's spreadsheet and I think that
will do us for a while anyway.

BTW, while I'm wrapping up this subject,
isn't there a way to provide a compiled version
of the app for common OSs for those who don't
want to set up a develpment environment to
recompile it? Might widen your market a bit.

Lastly, your required list only shows Ant,
but my understanding is that Ant requires Apache.
If so, you might want to list that up front
as a requirement. My IT people were a bit
put out after getting all the pieces on the
(IIS) web server to find that it needed
apache. They wished they had known that up front.

Thanks,
Brad.

Your message has been successfully submitted and would be delivered to recipients shortly.