Learn with our tutorials and training

developerWorks provides tutorials, articles and other
technical resources to help you grow your development skills
on a wide variety of topics and products. Learn about a specific
product or take a course and get certified. So, what do you want to learn
about?

Featured products

Featured destinations

Find a community and connect

Learn from the experts and share with other developers in one of our
dev centers. Ask questions and get answers with dW answers. Search for local events
in your area. All in developerWorks communities.

Best practices for effective velocity tracking

Tools and techniques

J. Jeffrey HansonPublished on December 04, 2012

Velocity is a measure of productivity that project managers
sometimes use in Agile software development. You calculate the velocity by
counting the number of units of work completed in a certain interval,
which is determined at the start of the project. The main idea behind
velocity is to provide a lightweight methodology for measuring the pace at
which a team is working and to assist in estimating the time needed to
produce additional value in a software-development project.

This article explains the principles behind velocity tracking. It also
discusses the resources project managers use to assist in effective
velocity tracking, such as iterations, burn-down and burn-up maps,
backlogs, issue tracking systems, and project management software.

Introduction to velocity
tracking

You identify the rate of velocity by tracking the units of work needed to
complete all defined tasks in a given period of time, known as an
iteration. By tracking velocity, a project manager can
measure the speed at which a team progresses and, therefore, more
accurately determine the time required to complete a given project.

Units of work are elements of an Agile-based project such as
features, change requests, bugs, use cases, user stories, and others.
Tasks comprise one or more units of work completed during
iterations of a project cycle. Sometimes project managers refer to a
project iteration as an interval or sprint.

Project managers use velocity tracking to estimate the time needed to
complete an iteration of a given project. Tracking the velocity of a team
provides project managers with valuable metrics that they can use to
determine a team's performance over time.

Units of work

To calculate velocity, you must first define the units of work for each
task involved in a project iteration. You can define a unit of work using
hours, days, points of a user story, or any other arbitrary unit that you
can consistently measure across multiple projects. Each task in a project
is evaluated in terms of the unit of work.

Throughout each iteration of a project, teams record completed tasks and
units of work. At the completion of an iteration, a project manager
determines the units of work needed to complete each task.

Iterations

An Agile-based project is composed of iterations. Iterations are typically
between one and four weeks in length and produce a tangible
deliverable.

Before each iteration, a team holds a two- to four-hour planning meeting to
determine the breakdown of tasks. Each task is broken down into steps such
as specification writing, design work, code implementations, testing, and
debugging. Because effective velocity tracking depends on consistency, it
is important to not allow feature creep to sneak into an iteration.

Story points

Story points are arbitrary values you use to measure the effort
required to complete a user story. In most cases, project managers define
a story point complexity range as a Fibonacci series (for example, 1, 2,
3, 5, 8).

An accurate story-point value evolves over time. After a few iterations, a
team should be able to accurately determine how many points per hour it
takes to complete a unit of work.

Because velocity is defined as the number of story points a team can
complete per iteration, it is important to determine a team's velocity as
soon as possible.

Estimating velocity for the initial
project iteration

Velocity calculations tend to be a bit inaccurate at the start of a
project. However, these calculations improve with each iteration.
Therefore, for purposes of accurate velocity tracking, it is critically
important to maintain as much consistency (hours worked, days worked,
number of team members) as possible across iterations.

For the first iteration of the first Agile project undertaken by a team, a
general consensus is to use one-third of available project-implementation
time as the baseline value for estimating the velocity of a team. This
number allows for meetings, research, vacations, personal time off, and
administrative duties.

You must know the following to make an initial estimate:

The number of people participating in the project

The maximum amount of work any one person can accomplish during a
typical time period of the iteration

The total number of workdays in the iteration

Updating velocity values

A team's velocity becomes apparent as the first iteration progresses.
Underestimations in the initial velocity estimation cause the velocity
value to increase, and overestimations cause the velocity value to
decrease. You make adjustments to the velocity as real numbers present
themselves. You should use the adjusted velocity as a guideline for
subsequent iterations.

Subsequent iterations of a project use the numbers from previous iterations
to determine the amount of work a team can accomplish. In most
circumstances, the velocity rate starts to stabilize somewhere between
three and six iterations.

Tracking units of work

To effectively track units of work, you must collect as much data about
each unit of work as possible. Each unit of work has unique elements that
you can track. Elements that you should track for most units of work
include:

Status (started, in progress, completed)

How closely the unit-of-work description meets the actual
deliverable's requirements

How easily the unit-of-work description is understood

The estimated number of days to complete the unit of work and the
number that were actually needed

The actual number of hours per story point that were needed to
complete the unit of work

The number of points the unit of work merits

Determining team velocity

An existing team can determine its velocity by completing the following
steps:

Agree on a project iteration (for example, 10 workdays).

Gather a list of what the team completed in the previous 10 work
days.

List the work completed in story points to establish their sum and
corresponding velocity value.

Plan to deliver this number of story points in the team's first
iteration.

Add or remove points in the next iteration based on whether the team
completes the targeted number of story points.

Most teams determine their baseline velocity within about three
iterations.

For this formula to work, you need:

One team of two to eight members that remains consistent throughout
the project

A predetermined iteration duration

Enough units of work to keep the team occupied for the duration of the
iteration

Accounting for exceptions

Velocity is affected by inconsistencies in resource variables, such as team
member attendance (illnesses, vacations, and other personal-time leaves).
The loss of a team member must be accounted for. Replacing a team member
typically involves the time of other members of the team. Therefore, team
velocity will most likely suffer until the new team member is in place and
up to speed.

Tools

It is essential to have the proper tools on hand to facilitate proper
velocity tracking. Some of the more obvious tools handle jobs such as
story gathering, iteration planning, progress monitoring, and reporting.
Project managers typically employ spreadsheets, issue tracking tools,
story or index cards, story-planning boards, and project-management
applications to address velocity-tracking management.

Some of the more widely used tools for velocity tracking responsibilities
include:

See Related Topics at the end of this article for links to these and other Agile
development and velocity-tracking tools.

One of the most important tools for effective velocity tracking is a set of
accurate reports. Next I'll cover some of the most widely used reports for
Agile project management and velocity tracking.

Reports

Agile reporting is essential for accurate velocity tracking. Because
velocity is a product of numbers gathered over time, it is vital to gather
and record as much pertinent data as possible. Table 1 lists and explains
some of the data points that you should record across iterations and
projects:

Table 1. Data points to record

Data point

Description

Average story-point size

This number helps teams understand how consistent they are at
estimating story complexity.

Iteration completion discrepancies

These values help teams understand how accurate they are at
estimating iteration delivery dates.

Burn-down rate by project

These values help teams understand their rate of completion
across multiple types of work.

Burn-down rate by task

These values help teams understand the rate-of-completion
trends throughout the iterations of a project.

Project managers track these data points and other important items using
some typical Agile-based reports and charts.

Product backlog

A product backlog is a spreadsheet-like prioritized list showing
the units of work that are to be assigned or implemented for a given
project. Each story or bug listed in the product backlog should
include:

A unique identifier

The type (feature, change request, or bug)

The status

The priority

An estimate of completion

You should update the product backlog on a weekly basis.

Iteration backlog

An iteration backlog is a spreadsheet-like prioritized list
showing the tasks that are yet to be assigned or implemented for a given
iteration. Each task line item should include:

A unique identifier

The task description

The task author

The task owner

The status

The number of remaining hours until task completion

You should update the iteration backlog on a daily basis.

Charts

Agile development tools deal with a set of metrics that is quite different
from those tracked with traditional project-management tools. Agile
development tools focus on business value rather than traditional metrics
such as hours worked or critical paths, using artifacts such as burn-down
charts, burn-up charts, velocity charts, and others.

A burn-down chart shows the work remaining in an iteration. This
chart requires a project manager to monitor the status of an iteration
continuously and estimate the remaining work for that iteration.

Burn-down charts help you see the trends of a given iteration. Figure 1 is
an example of a burn-down chart that shows the desired velocity for the
iteration (red) and the actual velocity (blue). I used Excel to generate
this chart.

Figure 1. Burn-down chart

A burn-up chart tracks the progress in story points of a given
project. Like a burn-down chart, this chart also requires a project
manager to monitor the status of an iteration continuously and estimate
the remaining work for that iteration.

Burn-up charts help you see the progress of a given iteration. Figure 2 is
an example of a burn-up chart that shows the total story points for the
entire project (blue) and the sum of completed story points (red). I used
yED Graph Editor to create this chart.

Figure 2. Burn-up chart

A velocity chart shows velocity across all iterations of a given
project. The data source for the chart is the product backlog. The
horizontal axis represents iterations, and the vertical axis represents
the effort, in units chosen by the team (for example, story points or
hours), that the team has expended.

A typical velocity chart for an Agile project team might look like Figure
3, which illustrates the velocity trend (red) across all iterations of the
project. I created this chart in Excel.

Figure 3. Velocity chart

Issue tracking

Agile development uses issue tracking tools and techniques in a slightly
different manner than traditional development. The definition of an issue
in Agile development is broader than typical uses of the term, including
items such as bugs, change requests, feature requests, user stories, and
others. An issue is anything that needs to be fixed or delivered
within a project's life cycle or iteration.

As issues present themselves in Agile development projects, teams must deal
with them immediately. These issues are embodied as stories in the product
backlog. Each issue that arises in the product backlog must be addressed
and resolved before an iteration is complete. Therefore, the product
backlog becomes a vital tool for tracking issues in an Agile development
project.

Conclusion

This article examined the concepts behind velocity tracking and provided
examples of the primary tools and techniques used to manage and measure a
team's velocity within the scope of an Agile project. Although you can use
the techniques discussed here for most typical projects, remember that
each project has its own subtle nuances that you should factor in as
needed.

Velocity tracking is an effective way to track a team's ability to get work
done. However, effective velocity tracking relies on a consistent and
concerted effort on the part of project managers and team members to track
work efforts and estimations closely so they can refine velocity values
and resultant project estimations.