Software Development Cross Solution - Index of - Free

factoring in real velocity
Q: A team velocity of 0.6!? That’s
even slower than before. What happened?
A: Based on the work done in the last
iteration, it turned out that your team was
actually working a little slower than 0.7.
Q: Shouldn’t my velocity get quicker
as my iterations progress?
A: Not always. Remember, velocity is a
measure of how fast your team can burn
through their tasks, and 0.7 was just an
original rough guess when you had nothing
else to go by.
It’s not uncommon for you and your team to
have a tough first iteration, which will result
in a lower velocity for the next iteration. But
you’ll probably see your velocity get better
over the next several iterations, so you’ve
got something to look forward to.
Q: Hmm, I noticed that some of the
estimates for the Orion’s Orbits user
stories have changed from when we last
saw them in Chapter 3. What gives?
A: Good catch! Based on the knowledge
that you and your team have built up in the
last iteration, you should re-estimate all your
stories and tasks. Now you know much more
about the work that will be involved so new
estimates should be even more accurate,
and keep you from missing something
important, and taking longer than you expect.
358 Chapter 10
Q: So the estimates for our user
stories and their tasks will get smaller?
A: Not necessarily. They could get smaller,
or bigger, but the important thing is that they
will likely get more and more accurate as
you progress through your iterations.
Q: I see that bug fixing is also
represented as a user story. Doesn’t that
break the definition of a user story a bit?
A: A little, but a user story really ends up
being—when it is broken into tasks—nothing
more than work that you have to do. And a
bug fix is certainly work for you to take on.
The user story in this case is a description
of the bug, and the tasks will be the work
necessary to fix that bug (as far as you and
your team can gauge from the description).
Q: I’m really struggling coming up
with estimates for my bugs. Am I just
supposed to take my best guess?
A: Unfortunately, you will be taking a
best guess. And when it comes to bugs, it
pays to guess conservatively. Always give
yourself an amount of time that feels really
comfortable to you. And remember, you’ve
got to figure out what caused the bug as well
as fix it; both steps take time.
One technique you can use is to look for
similar bugs in the past and see how long
they took to find and fix. That information
will at least give you some guide when
estimating a particular bug’s work.
Download at WoweBook.Com
Q: If I have a collection of bugs, how
do I decide what ones should make it
into the board and be fixed in the next
iteration?
A:” You don’t! Priority is always set
by the customer. So the customer sets a
priority for each of the bugs, and that’s what
tells you what to deal with in each iteration
Besides, this approach lets the customer
see that for each bug that is added to the
iteration, other work—like new functionality—
has to be sacrificed.
The decision is functionality versus bug fixes,
and it’s the customer who has to make that
call... because it’s the customer who decides
ultimately what they want delivered at the
end of the next iteration.
Q: I understand why the high-priority
stories made it onto the next iteration’s
board, but wouldn’t it be a better idea to
add in another high-priority user story
that slightly breaks the maximum work
limit, rather than schedule in a lower
priority task that fits?
A: Never break the maximum working
days that your team can execute in an
iteration. That value of 36 days for the
maximum amount of work your team can
handle for an iteration of 20 days is exactly
that: the maximum.
The only way that you could add more work
into the iteration is to extend the iteration.
You could fit in more work if your iteration
were extended to, say, 22 days, but be
very careful when doing this. As you saw
in Chapter 1, iterations are kept small so
that you can check your software with the
customer often. Longer iterations mean less
checks and more chance that you’ll deviate
further from what your customer needs.