Software Development Cross Solution - Index of - Free

Velocity accounts for overhead in your estimates
It’s time to add a little reality to your plan. You need to factor in all those annoying
bits of overhead by looking at how fast you and your team actually develop software.
And that’s where velocity comes in. Velocity is a percentage: given X number of
days, how much of that time is productive work?
Take the days of work it will take you
to develop a user story, or an iteration,
or even an entire milestone...
days of work
velocity
...and DIVIDE that number by your
velocity, which should be between 0 and
1.0. Start with 0.7 on a new project as
a good conservative estimate.
But how can I know how fast
my team performs? We’ve only
just gotten started!
Start with a velocity of 0.7.
On the first iteration with a new team it’s fair to assume
that your team’s working time will be about 70% of
their available time. This means your team has a velocity
value of 0.7. In other words, for every 10 days of work
time, about 3 of those days will be taken up by holidays,
software installation, paperwork, phone calls, and other
nondevelopment tasks.
That’s a conservative estimate, and you may find that over
time, your team’s actual velocity is higher. If that’s the case,
then, at the end of your current iteration, you’ll adjust
your velocity and use that new figure to determine how
many days of work can go into the next iteration.
Best of all, though, you can apply velocity to your amount
of work, and get a realistic estimate of how long that
work will actually take.
= days required to
Download at WoweBook.Com
get work done
project planning
Yet another
reason to have
short iterations:
you can adjust
velocity frequently.
The result should always be BIGGER than
the original days of work, to account for
days of administration, holidays, etc.
Seeing a trend? 30 days of a calendar
month was really 20 days of work, and
20 days of work is really only about
15 days of productive time.
you are here 4 89