Creating a Smarter Velocity Chart – Part 2

In my previous blog entry, A Smarter Velocity Chart for Effective Communication, I explained what a velocity chart is and why it is an effective tool for communicating project information to stakeholders. In this write-up, I’ll provide a true-to-life IT scenario to detail the steps for creating velocity charts.

Estimating Effort

Developing a velocity chart starts with effort estimation. We do this by working with the project team to identify the critical quantitative project deliverables, weigh the amount of effort required and assign points values to each. The starting points themselves are somewhat arbitrary, but the key is to ensure the points values accurately reflect the effort of the deliverables relative to one another.

Using Agile estimation principles as outlined by Scrum Alliance, point differentials are quantitative weights predicated on effort, not time. Whether you choose to value something at one point, 100 points or 1,000,000 points, it’s an arbitrary number. The key is to ensure the values assigned to deliverables are comparative to one another.

For example, let’s say I am working on a virtual desktop infrastructure project, and in this project we’ll be deploying a thousand workstations across forty different departments, building ten servers and building two different images. To start, we decide each workstation is worth one point. A workstation’s defined points value then becomes the comparison for determining the points associated with the remaining deliverables.

Next, we determine a server requires much more effort compared to a workstation and should, therefore, be worth 100 points each. Building an image requires twice as much effort as a server, so we deem that to be 200 points each. Finally, as we are deploying to multiple departments and each one is a significant milestone, we decide those deployments are worth five points each because of communication, coordination and other efforts. These totals are reflected below:

Documentation stating the required effort for each task item is listed here.

Building the Velocity Chart

After determining the effort estimate, we begin building the velocity chart per the T2 Tech Group methodology. To illustrate how to build a velocity chart to track progress, we’ll revisit some key terminology discussed in my previous blog pertaining to the sections of the chart:

Original Scope: This section is where I enter the total project weight of all deliverables identified at the beginning of the project.

Original Forecast: This section is where I enter the total effort points forecast to be earned, as reflected by completed deliverables, at the end of each iteration based on the backlog and project plan.

Current Scope: This section is where I enter the current total project weight of all deliverables, including scope changes. I will update this value at the end of each iteration, as scope may increase or decrease during that time.

Current Forecast: This section is where I enter my current forecast based on factors such as changes in project scope or decreases/increases in productivity.

Completed: This section is where I enter the total effort points earned at the end of each iteration, as reflected by the sum of points values for completed deliverables.

Based on those points from our effort estimation, the baseline values are as follows:

Based on those points from our effort estimation, the baseline values for the original scope and original forecast are listed here.

As the project progresses and work is completed, I continually update the Current Scope, Current Forecast and Completed cells in the table to reflect current total project weight, including scope changes and the effort points earned. The table below reflects inputs I made over the course of this project:

Continuous updates from the current scope, current forecast and completed are reflected in this table.

To provide context to the table above, let me walk you through what happened during this sample project and how the values above reflect those outcomes. The scope was increased twice during the product, on 13-Oct from 2600 points to 3000 points and on 10-Nov from 3000 points to 3200 points. These changes impacted the project end date and required I update the Current Forecast section to account for these changes.

As shown in the Completed row, the team was more productive than the Original Forecast predicted. Within the second iteration, 15-Sep, 200 points were forcasted to be completed, but 300 points were actually completed. After this, the team continued to meet or out perform the Original Forecast, and by 24-Nov, the Original Scope of 2600 points was completed when only 2200 points had been anticipated. Given the overall increase in scope, the Current Forecast predicts the project will require additional iterations to complete the Current Scope of 3200 points.

The Resulting Velocity Chart

All the information entered in the table above feeds into the velocity chart developed by T2 Tech Group. Based upon the inputs entered, the resulting velocity chart below reflects my hypothetical project scenario:

 

In Summary

To create our velocity chart, teams must (1) estimate effort of deliverables relative to one another, (2) build the chart using effort estimates to establish the baseline scope of work, and (3) continually update the chart as the project progresses. Most of the effort required to create a velocity chart is invested in the initial effort estimation. Once this is completed, periodic updating of the chart after each iteration can be accomplished quickly. If you’re an IT project manager like myself, you’ll find this velocity chart can be a great tool for showcasing project completion status in a meaningful way. I encourage you to share your perspective about this velocity chart methodology in the comments below.

About the Author:

Justin Brayman
Justin is a project manager with over eight years of experience in information technology, security and commercial construction. As a T2 Tech Group project manager, he manages high-profile projects and IT operations for large health systems. In this role, he has overseen new hospital tower construction initiatives and largescale technology transformations for organizations such as Kootenai Health and Verity Health System. Justin’s past roles before joining T2 Tech include acting as a project manager for Intrinium, Inc and a project estimator at Great Floors. He has a Bachelor of Arts in Elementary Education and PMP, SFC, Six Sigma Yellow Belt and ITIL Foundation certifications.

Leave A Comment