Your team’s velocity is most easily defined as the number of Story Points they are able to complete fully within a single iteration.

Once you understand your team’s velocity, you can more confidently commit your team to complete a specific number of story points for the next iteration. But how do you factor velocity when the project has just begun?

Here we take a look a the Velocity Guess based on Historic Progress. It’s a method that has served us well in the past.

Guessing your Velocity

Their are two distinct ways to calculate your team’s velocity on a project. The first is the Historic Guess where experience from past progress on similar features is used to estimate a team’s velocity on upcoming features.

Lets assume your team is asked to implement a product management system for an E-Commerce web application. The stories for this system might look like this:

#	Story	PTS	Iteration
1.	As an admin I want to create a product record by uploading a photo of the product and entering pricing information	8
2.	As an admin I want to update a products price	3
3.	As an admin I want to update a products description	3
4.	As an admin I want to update a products photo	3
5.	As the system when an admin uploads a photo for a product I want to resize it to fit the interface	5
6.	As an admin I want to deactivate a product	1
7.	As an admin I want to activate a product if it is deactivated	1
8.	As an admin I want to assign a product to multiple categories	5
9.	As an admin I want to view a history of previous orders for a product	8

The team had recently completed a similar application a few months ago and in a meeting on the topic agree that although it’s not exactly the same, it’s similar enough to be used in a Velocity Guess.

During that project, the team was asked to create a simple item catalog. The aspects of creating a catalog in the previous project is quite similar to the product manager here. Since the team averaged about 10 points a week it’s suggested that it would be a good guess to set the velocity at 10 and move on with production.

Factoring in the Unknown

However, during the discussion, someone points out that the previous catalog used pre-formatted imagery from a graphics artist. The client want’s this system to automatically handle the image processing and that’s something the team hasn’t done before. The other project didn’t take order histories into account either… that’s something the team will have to build from scratch and there is debate among the team as to the best method to implement that feature.

Based on these revelations, the team decides that while many stories are similar to the previous project, there is still enough uncertainty to prevent the team from using the previous velocity.

In such situations it’s necessary to provide a velocity range.

Defining the Margin of Uncertainty

The team reviews the proposed stories and note that only 2 of the stories (#5 and #9) are risky. These contribute roughly 30% of the projects total point values. However, 80% of the stories are very similar to their previous project. The team decides that they can’t commit to 10pts / iteration based on the existing uncertainty. However, if they were given a full week to research and implement the risky stories, they could commit to 8pts.

Given the teams commitment to the other 80% of the features, the project owner decides to assign a 25% margin of uncertainty to the velocity estimate. If more high risk stories were present, the range could be as high as 60%, but for now this margin feels comfortable.

This provides the team with a 5-11 point range with 8 points being the target goal.

In this case, the team can commit to a desirable number of stories while still taking the uncertainty of the new stories into account. As the risky stories are further planned, and a more solid understanding of their implementation is gained, the team can reduce the margin of uncertainty and provide a more solid estimate.

The Iteration Plan

With the final Velocity Guess obtained, the team publishes a new iteration schedule.

#	Story	PTS	Iteration
1.	As an admin I want to create a product record by uploading a photo of the product and entering pricing information	8	1
2.	As an admin I want to update a products price	3	2
3.	As an admin I want to update a products description	3	2
4.	As an admin I want to deactivate a product	1	2
5.	As an admin I want to activate a product if it is deactivated	1	2
6.	As an admin I want to update a products photo	3	3
7.	As the system when an admin uploads a photo for a product I want to resize it to fit the interface	5	3
8.	As an admin I want to assign a product to multiple categories	5	4
9.	As an admin I want to view a history of previous orders for a product	8	5