If trying to give a small and simple definition, then Agile Velocity is the amount of work
your team gets in a given time.
Agile development does not necessarily lend itself like a
dashboard and report to the beloved by the managers. Some metrics in Agile Velocity seem very little in
terms of its production team's plan. Given this lack of usable information, it
can again tempt the purpose Agile
Velocity as a measure of productivity. After all, this is a measure of the
capacity of the team, so it is thus that changes over time can be used to
indicate the overall change in productivity?
The problem with this approach is that Agile Velocity is a planning tool rather than a specific measurement. This is
an estimate of the relative potential that varies with time, and these changes
do not necessarily indicate a change in productivity. This is an arbitrary
measure which is wildly different among teams. There is no reliable means of
converting it into generalized data which can be used for meaningful
comparison.
What you measure in Agile Velocity, You get
Given that Agile
Velocity is such an arbitrary measure, which is easy for the game. By
equating Agile Velocity with productivity, you create a "distorted
incentive" to optimize velocity at the cost of developing software.
Consciously or not, teams will try to demonstrate an increase in productivity
by massaging them upwards. Even worse, they can start cutting corners to
distribute things with short story points. This could lead to the creation of a
technical debt that could work productivity in the future.
If you distribute burn-down charts to senior management,
then you see the same behavior. Each sprint, the progress line magically starts
intersection with the distribution target. The size of the line can be wildly
different, but in some way can be slower in the second part of the sprint to
meet the speed or slow speed.
Agile Velocity is
a measure of the amount of work that a team can do. This is not the same as
measuring the value or effect of this work. Velocity can actually be relatively
stable in a successful and well-established team because the amount of raw
effort available for each sprint remains constant. In this case, putting
pressure on the Agile Velocity of artificial will only accomplish perverted
estimates.
Can You Actually Measure Software Productivity?
Productivity is determined by seeing the input and output of
any activity. Measuring the input for software development is quite easy, but
in fact it is difficult to measure the output in any consistent way.
A raw, quantitative measurement, like the number of rows of
code, does not provide a proper direction. It depends on wildly changing
factors like coding style, development language and implementation approach in Agile Training. It can also be
counter-intuitive as well written code which takes time in crafting often
requires less lines of code.
Systems based on function points or relative complexity can
give slightly better fare, but they are still much correlated to the code that
is being written instead of the value being distributed. They can add a lot of
overhead in the process of Agile Development
in the case of collecting and interpreting data.
Are Professional Results Enough?
If you measure productivity by Agile Velocity you will see a statistical improvement. It is not
similar to successful development. Ultimately, the tight process should
establish a continuous reaction loop between development teams and commercial
references. A more meaningful solution to success should be taken into account
and focus on the benefits of real world rather than intangible measures or
generalized indicators.
The problem is that these measures vary wildly between teams
comparing any kind of cross-team, but all are impossible. Web teams will not
constantly measure the real world because web teams can focus on increasing
visitors and conversions, while infrastructure teams can have more technical
goals around throughput and heritage.
A leap of confidence is necessary here because team
productivity cannot be substantially reduced to normalized score. The teams
should collect their own data and measure their productivity to manage their
continuous improvement. The possibility of focusing on concrete benefits is
likely to be echoed with teams and provide something for them to work
collectively. It will provide a more consistent measure over time, because in reality
the world profits are less prone to variation due to the structure or
development approach.
Metrics are not a bad thing, but are wrong.
Metrics are not just a management enjoyment. They help you
identify problems; decide on corrective action or how to develop in the future.
However, it is difficult to reach a productivity measure, which can be applied
appropriately across the board for software development. By satisfying the
hunger of on-going management for reports and dashboards, you take the risk of
creating meaningless overhead and distorting the development.