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.
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.
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.
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 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.
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
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.
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
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
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.
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:
- Microsoft Excel (burn-down, burn-up, and velocity charts)
- Pivotal Tracker (story points, burn-down, burn-up, and velocity charts)
- VersionOne (burn-down, burn-up, and velocity charts)
- IBM Rational Team Concert™ (burn-down, burn-up, and velocity charts)
See Resources 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.
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
|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.
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.
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.
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. 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. 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. Figure 3. Velocity chart
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.
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.
velocity@scale (M. Kevin McHugh, developerWorks, 2012): Read this excellent ongoing multipart blog series to learn more about measuring and predicting velocity in Agile projects.
- Acceleration: An Agile Productivity Measure (Scott Ambler, developerWorks, October 2008): In this blog entry, Ambler compares velocity and acceleration as measures of productivity.
- Burndown and Velocity Example: The Agile Alliance shares a sample burn-down and velocity-tracking spreadsheet based on an actual project.
Get products and technologies
- Pivotal Tracker: Try Pivotal Tracker for free.
- VersionOne: Take advantage of a free trial to discover the capabilities of VersionOne.
- Rational Team Concert: Check out Rational Team Concert, which is free for small teams (10 developers or fewer) and open source projects.
- yED Graph Editor: The sample burn-up chart in this article was created with yED Graph Editor.
- TargetProcess is another good resource that's particularly effective for burn-down charts and velocity tracking.
- Jira and Trac: Plug-ins that enable Agile-based reporting and chart generation are available for both Jira and Trac.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- developerWorks Agile transformation provides news, discussions, and training to help you and your organization build a foundation on Agile development principles.
- Check out developerWorks blogs and get involved in the developerWorks community.