Software Development Cross Solution - Index of - Free

Q: How do you know the first graph
is things the team missed? Couldn’t it
be things they didn’t expect, like extra
demos or presentations?
A: Absolutely. The burn-down graph isn’t
enough to go on to determine where all
those extra work items came from. You need
to look at the completed tasks and figure out
whether the extra work came from outside
forces that you couldn’t control or if they
were a result of not really understanding
what the team was getting into. Either way,
it’s important to make progress in addressing
the extra work before the next iteration. If the
work came from outside sources, can you do
something to limit that from happening again,
or at least incorporate it into your work for
the estimate? For example, if the marketing
team keeps asking you for demos, can you
pick one day a week where they could get
a demo if needed? You can block that time
off and count it toward the total work left.
You can use the same approach if things
like recruiting or interviewing candidate
team members is taking time away from
development. Remember—your job is to do
what the customer wants. However, it’s
also your responsibility to know where your
time is going and prioritize appropriately.
If the extra work came from not
understanding what you were getting into, do
you have a better sense now, after working
on the project for another iteration? Would
spending more time during task breakdowns
help the team get a better sense of what
has to be done? Maybe some more up-front
design, or possibly quick-and-dirty code
(called spike implementations) to help shake
out the details?
Q: So spending more time doing
up-front design usually helps create
better burn-down rates, right?
A: Maybe...but not necessarily. First,
remember that by the time you start doing
design, you’re already into your iteration.
Ideally you’d find those issues earlier.
It’s also important to think about when is the
right time to do the design for an iteration.
Some teams do most of the detailed design
work at the beginning of the iteration to get
a good grasp of everything that needs to be
done. That’s not necessarily a bad approach,
but keep an eye on how efficient you are
with your designs. If you had driven a couple
stories to completion before you worked
up designs for some of the remaining ones,
would you have known more about the rest
of the iteration? Would the design work have
gone faster, or would you realize things
you’d need to go back and fix in the first few
stories? It’s a trade off between how much
up-front design you do before you start
coding.
Having said all of that, sometimes doing
some rough whiteboard design sketches
and spending a little extra time estimating
poorly understood stories can help a lot with
identifying any problem issues.
Q: For that third graph, couldn’t the
velocity be a big part of the problem?
A: That’s a possibility, for sure. It could
either be that the team’s estimates were
wrong and things just took a lot longer than
they thought the would, or their estimates
were reasonable but they just couldn’t
implement as fast as they thought. At the
end of the day it doesn’t make too much
difference. As long as a team is consistent
with their estimates, then velocity can
be tweaked to compensate for over- or
underestimating. What you don’t want to do
is keep shifting your estimates around. Keep
trying to estimate for that ideal workday
for your average developer—if that person
was locked in a room with a computer and
a case of Jolt, how long would it take? Then,
use velocity to adjust for the reality of your
work environment and mixed skill level on
your team.
Download at WoweBook.Com
ending an iteration
Q: So should the team with the third
graph just add time to the end of their
iteration to get the extra work done?
A: In general that’s not a great idea.
Typically, when the burn-down graph looks
like that, people are already working hard
and feeling stressed. Remember one of
the benefits of that graph on the board is
communication—everyone sees it at each
standup, and they know things are running
behind. Adding a day or two is usually OK in
a crisis, but not something you want to do on
a regular basis. Adding a week or two... well,
unless it’s your last iteration, that’s probably
not a good idea. It’s generally better to
punt on a user story or two and move them
to the next iteration. Clean up the stories
you finished, get the tests passing, and let
everyone take a breather. You can adjust
your velocity and get a handle on what went
wrong before you start the next iteration, and
go into it with a refreshed team and a more
realistic pace.
Q: We have one guy who just
constantly underestimates how long
something is going to take and wrecks
our burn-down. How do we handle that?
A: First, try to handle the bad estimates
during estimation, and remember, you
should be estimating as a team. Try
reminding the person that they aren’t
estimating for themselves, but for the
average person on your team. If that still
doesn’t work, try keeping track of the date
a task gets moved to In Progress, and then
the date it gets moved to Done. At the end
of your iteration, use that information to
calibrate your estimations. Remember, this
isn’t about making anyone feel bad because
they took longer than originally expected;
it’s to calibrate your estimates from the
beginning.
you are here 4 323