Joel on newer FogBugz schedulating
Peter McCurdy
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=497
(or http://tinyurl.com/2xylg6 )
In particular, he talks about calculating release dates based not on
the raw estimate supplied by the developer, but by looking at how each
developer generally performs relative to their estimates, which he
calls Evidence Based Scheduling. This is on page 4, if you just want
to skip to that, though the rest is interesting too.
Just an idea to keep in mind for future Schedulator development. If I
ever get around to doing more Schedulator work, the first thing I want
to add is some sort of display of how accurate people's estimates end
up, so at that point it might be easy to adjust displayed due dates
based on this.
Peter.
Avery Pennarun
> Just an idea to keep in mind for future Schedulator development. If I
> ever get around to doing more Schedulator work, the first thing I want
> to add is some sort of display of how accurate people's estimates end
> up, so at that point it might be easy to adjust displayed due dates
> based on this.
I agree with this in theory: multiplying each user's estimates by a
user-specific, auto-calculated value is cooler than using a single
global MagicDay factor.
However, we have to be careful not to mix up two separate Schedulator
features: per-task due dates and release date calculation. I think
the due dates should simply reflect your estimates, in order to
pressure you to get your work done (and after all, if your task gets
longer, the due date moves itself anyway). The project-wide summary
could be recalculated using a per-person factor, however.
> my biggest beef with the Schedulator was that I never actually
> got any feedback on how good my estimates were. I'd like to think
> they were generally sort of accurate, but I did have to fiddle with
> them a fair bit, and I had no (easy) way to find out what it actually
> worked out as. And he's right, they were almost certainly more often
> too short than too long.
I agree, feedback on estimates would be great. (Although if you use
fogbugz, it tracks Original vs. Current estimates for you anyway per
task - it's the project-wide schedule that doesn't have feedback.) It
would be quite straightforward to add as a schedulator4 plugin - we
just need a good way to *display* it once we have all the data.
Also note that Joel's traditional task estimation systems is a bit
weaker than schedulator's, which means his system had biases that
schedulator already fixed. For example, Joel doesn't like the
LoadFactor idea; he'd prefer to apply exactly 8 hours per day
(http://www.joelonsoftware.com/articles/fog0000000245.html), which is
probably why he finds his tasks end up more underestimated than
overestimated. If you don't have a load factor, and you estimate 4
hours for a task and it takes 6 hours, then you've underestimated -
but maybe only because someone interrupted you for 2 hours.
In fact, I find my own per-task estimates to be quite frighteningly
accurate (on average). Where I go wrong is that in fixing one bug,
I'll discover another one, or that during the project, new tasks get
added. In schedulator we compensate for this with the MagicDay
factor, but it's hard to base that on estimate-performance statistics:
it's not that my estimates were wrong, it's that new tasks *appeared*
during the project. You can compensate for that with historical
statistics too, of course, but I wonder whether the MagicDay is best
modelled as project-wide or person-specific.
Have fun,
Avery
Pierre Phaneuf
> Just an idea to keep in mind for future Schedulator development. If I
> ever get around to doing more Schedulator work, the first thing I want
> to add is some sort of display of how accurate people's estimates end
> up, so at that point it might be easy to adjust displayed due dates
> based on this.
Very loosely related is TeamTrac: http://teamtrac.org/
I haven't checked it out in details, but it looks like it's a kind of
schedulator... Among other things, instead of letting people set their
load factor, it looks like it just figures it out by itself.
Joe Mason
> Also note that Joel's traditional task estimation systems is a bit
> weaker than schedulator's, which means his system had biases that
> schedulator already fixed. For example, Joel doesn't like the
> LoadFactor idea; he'd prefer to apply exactly 8 hours per day
> (http://www.joelonsoftware.com/articles/fog0000000245.html), which is
> probably why he finds his tasks end up more underestimated than
> overestimated. If you don't have a load factor, and you estimate 4
> hours for a task and it takes 6 hours, then you've underestimated -
> but maybe only because someone interrupted you for 2 hours.
That reminds me - LoadFactor is kind of hard to explain and,
especially when you're starting out, it's hard to visualize what the
numbers mean. I've been thinking that a better interface to this
would be to have the user give the percentage of their attention they
can give to their scheduled tasks during the day - numbers like "80%"
or "90%" are much more meaningful at a glance. Then the LoadFactor
would just be the inverse.
Joe
Avery Pennarun
> That reminds me - LoadFactor is kind of hard to explain and,
> especially when you're starting out, it's hard to visualize what the
> numbers mean. I've been thinking that a better interface to this
> would be to have the user give the percentage of their attention they
> can give to their scheduled tasks during the day - numbers like "80%"
> or "90%" are much more meaningful at a glance. Then the LoadFactor
> would just be the inverse.
The word that popped into my head when you said that was "efficiency
rating", and of course that would work just as well. We could easily
add a new command in schedulator4 called "efficiency" that sets your
LoadFactor to the inverse of the parameter, and then we could have it
report *both* your efficiency and your load factor.
I think the term "load factor" comes from hardware engineering
somewhere. If an electric motor is loaded with only 0.50 of its rated
weight, it'll be able spin twice as fast. This leads to the slightly
weirder but obvious extension that if you load it to 2.0 times it
rated weight, it'll spin half as fast as it's rated. (In the case of
an electric motor, this is normally fine to do, as long as it's made
of strong enough materials.) The load factor in a human schedule
represents the same thing: if someone is doing 2.0 times as much as
his "rated" amount (the amount that's actually on the schedule), then
it'll take 2.0 times longer to finish.
The other, simpler way to think of it is that it usually takes me 2.0
days to do 1.0 days of work for whatever reason.
Inverting it makes me think of "efficiency" instead, which is actually
slightly the wrong concept. In all the examples above, the motor's
"efficiency" was the same: say 100%. It would be less "efficient" if
you gave it the rated load and rated input power, but for some reason
it still only spun at 70% speed.
Lower efficiency implies that things are broken and should be fixed.
Higher load factor implies that external factors are affecting the
speed of results, and that might be normal. But both could be
represented as either a percentage or a multiple, and both have the
same effect on output rate.
In summary, I think the load factor multiple is a more "accurate"
representation of what's actually going on, and doesn't encourage
wrong thinking (striving for 100% efficiency is obvious... and also
wrong). However, I can also see it both ways. I think schedulator
should probably support both ways of thinking, in case that helps
someone.
A more accurate word than "efficiency" would be nice to use though.
Have fun,
Avery
Joe Mason
> A more accurate word than "efficiency" would be nice to use though.
I was thinking of calling this the "attention factor" - it's how much
of your undivided attention you're actually giving to the task listed.
Joe
Avery Pennarun
That's a good name. It's not really a "factor", though, it's more of
a fraction. So we could present the stats like this:
Attention=50% -- Loadfactor=2.0
Have fun,
Avery
Peter McCurdy
>
> On 31/08/2007, Joe Mason <j...@notcharles.ca> wrote:
> >
> > On 8/31/07, Avery Pennarun <apen...@gmail.com> wrote:
> > > A more accurate word than "efficiency" would be nice to use though.
> >
> > I was thinking of calling this the "attention factor" - it's how much
> > of your undivided attention you're actually giving to the task listed.
>
> That's a good name. It's not really a "factor", though, it's more of
> a fraction. So we could present the stats like this:
>
> Attention=50% -- Loadfactor=2.0
This all sounds reasonable to me, but my only beef with the LoadFactor
was that sometimes it just wasn't how my schedule worked out. I found
that generally, rather than having a certain percentage of my time
taken up with unscheduled things, I rather had a certain amount of
overhead taken out of every day. For instance, when I ended up
working a half-day, I'd hardly get anything done (less than would be
predicted by dividing 4 hours by my LoadFactor), whereas if I worked
more than 8 hours, the extra time almost always went straight into
bugs.
So in short, if I were redoing the LoadFactor, I'd change it into a
measure of "average hours per day of overhead". On the plus side,
this is also pretty easy to explain. On the downside, it'd be a lot
more work than just adding the attention rating version of the current
LoadFactor, and I'm sure there are other people who would still want
the current LoadFactor way of doing things so it won't simplify
anything. Oh well, just another thing to go in the feature
wishlist....
Peter.
Pierre Phaneuf
> This all sounds reasonable to me, but my only beef with the LoadFactor
> was that sometimes it just wasn't how my schedule worked out. I found
> that generally, rather than having a certain percentage of my time
> taken up with unscheduled things, I rather had a certain amount of
> overhead taken out of every day. For instance, when I ended up
> working a half-day, I'd hardly get anything done (less than would be
> predicted by dividing 4 hours by my LoadFactor), whereas if I worked
> more than 8 hours, the extra time almost always went straight into
> bugs.
That seems pretty realistic to me, since past 8 hours, you're having
less and less people around and interrupting. Also, it explains how
you can lower your LoadFactor to push yourself (and also why this is
probably a bad idea over a sustained amount of time).
Joe Mason
> was that sometimes it just wasn't how my schedule worked out. I found
> that generally, rather than having a certain percentage of my time
> taken up with unscheduled things, I rather had a certain amount of
> overhead taken out of every day. For instance, when I ended up
> working a half-day, I'd hardly get anything done (less than would be
> predicted by dividing 4 hours by my LoadFactor), whereas if I worked
> more than 8 hours, the extra time almost always went straight into
> bugs.
Well, if you're just taking a half day off every once in a while
(illness, holiday, whatever) then it's not going to mess up your
schedule much over the long term. If you're consistently working a
half day, I don't see why your LoadFactor wouldn't work out - you'd
just have to estimate it from scratch instead of just taking a
LoadFactor you decided on when you were working 8 hours and applying
it to your new 4 hour schedule.
It's only if you have a completely mixed schedule that you'd have
problems (say I decided to use one vacation day a week to take every
Thursday and Friday afternoon off). That's a pretty rare case,
though. Except maybe for consultants...
Joe