- In agile development,
velocity is a measurement metric
that's used to determine
how much work an agile team can do over a period of time.
The period of time is usually a sprint,
so you might also hear this defined as sprint velocity.
Velocity depends on how your team decides
to weight user stories and tasks.
Whether it's with points, features, or some other metric,
it's important to keep it consistent.
Otherwise, your velocity will end up fluctuating,
and it'll make it hard to get any usefulness out of it.
Being that velocity is a measurement over time,
the question at the beginning of a project
is how to set the baseline.
It's a good rule of thumb
to think of your potential development velocity
as about 30% of your actual sprint time.
Now, that may seem like you're low balling yourself,
but I'm sure you're no stranger
to meetings, emails, random questions
that turn into hours and the like.
Limiting your first sprint to tasks,
you can realistically deliver
in 30% of your total available working time,
will start things off right,
and give your team a fair baseline velocity.
Whether you hit that mark or not,
will tell you a lot
about how you and your other developers work
and what needs to improve.
Once you have a baseline velocity,
each successive sprint can be planned more effectively.
You want this to be steady or, if possible, increasing,
so if you aren't hitting your sprint goals,
decrease the load in the next sprint.
Conversely, if you go through the sprint tasks with ease
and some extra time, load up the next one a bit more.
After the fifth or six sprint,
your team velocity will stabilize,
and you'll have a new, solid team metric.