Project Velocity

I l @ ve RuBoard

Project velocity is a tangible metric of the pace at which the team can produce deliverables. It is based on actual performance, not wishful thinking. When velocity slips, the team needs to find out why and fix it. Everyone on the team is accountable. If a team is able to do five stories this iteration and only two the next , there is a problem that needs to be solved . Were there less ideal work hours this iteration? If so, why? Did everyone put in a full work week?

Continuous integration may seem slower, but you will soon see that it makes projects go faster.

The project you are working on may have a business requirement to achieve a certain velocity, in which case the project manager needs to define a team size to accommodate this pace so that members work a reasonable and consistent amount from iteration to iteration. Keep your stories somewhat equal in work effort. Wild variations in story size make tracking velocity very difficult.

Whether you have a required velocity or a fixed team size, your goal is to develop consistency and predictability. Your customer needs to know how much she can count on receiving from your team in each iteration and at what cost.

Estimating Velocity

Velocity is not a set function of the number of team members times work hours equaling some number of lines of code or pages. It can be assessed only after a number of iterations as a function of the individual scope that can be completed by each member of the team.

We use " yesterday 's weather" to make our predictions about how the team will perform in the future. That is, we start with a guess, see what happens, and use the results as our next guess. If stories are approximately equal in scope and complexity, then the number of "ideal development hours" (hours of noninterrupted work) that it takes to do the first ten stories should be the same for the next ten stories.

It takes a number of iterations to figure this out because tracking an actual ideal development hour can be tricky. Most of the things that cut into ideal time should be removed in the first few iterations. Then estimates become more predictable when each developer can see her own patterns. Many meteorologists today use history in their predictions. They look at the last 100 days on which conditions were the same as on the current day. If it rained on 30 of those 100 days, then the chance of rain is 30 percent.

Why Is Velocity Important?

Nervous customers make life hell for the team. A consistent velocity that predictably delivers functionality every two weeks puts the customer at ease. If the velocity is not adequate, the customer has the option of increasing the budget and adding team members. If you are going to negotiate with a customer over how much he can expect from a team, you have to be able to show a consistent project velocity and back it up with estimates and actuals. You should be able to do this by tracking the first three iterations.

Changing Velocity

What happens when three people leave the team and are replaced by new staff? What happens when the programming language is changed? How will this effect velocity? Such changes will definitely have an effect but how much is unknowable. Changes to the team or to the nature of the project will impact the project in unpredictable ways. Only after measuring a number of iterations will you have a clear picture of this impact and be able to establish a new project velocity.

I l @ ve RuBoard