Some Thoughts on Project Velocity
Join the DZone community and get the full member experience.
Join For Free
This need can
result in pretty bad behavior on the part of both management and teams.
To gain some sense of certainty, management does things like ask teams
to provide estimates in real hours... and then hold the team
accountable for delivering exactly according to that estimate. Faced
with an impossible situation, teams are incented to game the numbers.
They overestimate the project... to provide some necessary buffer...
thus resulting in overinflated budgets. All this leads to a total lack
of trust on both sides.
Velocity is intended to bridge the gap
between management and the team. Teams get to measure project scope in
relative units such as story points. Point estimates are specific to
the team and measure how big one feature is relative to another in the
backlog. Teams then begin building the features and measure how much of
the backlog they are able to complete every iteration. After a few
iterations, the team should have a pretty good idea how long it will
take to complete the project.
Iterations to Complete = Backlog Size/Points per Iteration
For
this equation to work, for velocity to be a meaningful metric, it has
to be predictable... past performance must at some point become
indicator of future performance.
Furthermore, velocity is only
relevant to the business if we have a decent understanding of the
overall scope of the project. That means we have to have a meaningful
view into the backlog... for at least the upcoming release... sometimes
the entire project. Measuring velocity against a constantly changing
backlog doesn't give me a whole lot of information. If we are going to
have any idea of what done looks like at the project level, we need to
understand both backlog size and velocity... and understand how these
metrics might change over time.
Velocity is fundamentally a
measure of team throughput. How fast are we able to go... iteration
over iteration... against a relatively stable queue of product
features. These two metrics are the only thing standing between an
agile team and total choas... at least when it comes to overall project
performance.
To make all this work... both sides have to do their part. Ask not what your agile project can do for you... ask what you can do for your agile project.
Here are a few thoughts on what managers and teams can keep in mind to
keep velocity a reliable indicator of project performance... and maybe
build a little trust while we are at it.
Responsibilities of Management
Realize
that estimates are just that, estimates. As management, we can expect
that estimate should get better over time, but what we get early...
even in story points... is likely to change. We need to be prepared to
deal with change.
Management should only use metrics like
velocity as an indicator of project health and to help guide the
project into a successful outcome. If management uses velocity as a
lever or a performance metric, people will game the system to make the
numbers look right. You'll get the numbers you want, you might just not
get the product you want.
The size of the backlog has to be
stable or the project is out of control. We can't just keep changing
our minds indefinitely. We want to defer as many decisions, as long as
possible, but we need to have a fundamental understanding of the
product we are building and why. Constant churn will slow the team down
and make everybody frustrated.
Responsibilities of the Team
Estimates
are just that estimates. That said, we are accountable for making them
better over time. At some point we have to be able to tell the business
what they are going to get and when they are going to get it.
As
team members we have to realize that our velocity must stabilize.
Stable velocity is the life-blood of a predicable agile team. If we
can't stabilize our velocity, the business will always see our project
as out of control... because it is. We cannot expect the business to
continue to invest never knowing what they can expect to be delivered.
We
have to be honest with ourselves and our customers about what it really
means to be done at the end of an iteration. Gaming the system to make
the numbers look right will kill a project... hiding undone work in
future iterations doesn't help either.
From Agile Chronicles
Opinions expressed by DZone contributors are their own.
Comments