Every business needs a way not just to track progress, but also predict the progress. No one likes deadlines, but they’re a necessary evil. Clients need their work done when they expect it, but we (software engineers) also have to manage those expectations. Because, as we all know, client expectations are not always accurate.

Personally, I am a big proponent of using team velocity.

1. Team velocity tempers client expectations, because:

2. it gives the business a tried and true method of when to expect project completions, which:

3. allows software developers to focus on what they do best.

Measurement

The whole idea behind team velocity is: not to create the stress of deadlines by setting an arbitrary timeline for a ticket. Its purpose is to use progress, you as the software team either think you can achieve or progress you have documented over a certain period of time as the guideline.

Instead of using time as the determining variable for the completion of a story or project, you’re assigning the team points.

I use a Fibonacci point scale (0,1, 3, 5, 8).

In our iteration planning meetings (our planning meetings for the next two weeks), we sit together as a team and talk about various stories.

For example, we may need to add coupon codes to checkouts.

We break this down into smaller stories as a team, and assign points to each story. The point total for each story adds to the total amount we complete and gives us a total point count each week.

We can look at the point count over our two week iteration or by how many points are accomplished in a week.

If you do that with a team....I like to do it for three months...... but if you’re able to do it for at least 3 weeks, you should have a velocity for the team. Which is an average of points completed over those 3 weeks.

By establishing a team velocity, the business is never approaching the developers inquiring “When will this be done? What date? How soon?”

Effects of Velocity

As a developer, when you’re trying to get into your groove and get your code going, writing good software and trying to hit deadlines can definitely take its toll. The team’s velocity can tell the business owners when software will be delivered, not random time frames that will break a developer.

It’s all about shipping working software.

If we don’t hit deadlines that were set up by our intended and previously achieved velocity, then we go in and take a deeper look at what caused the problem. Then, we adjust accordingly.

Software engineers need to be:

• Pair Programming

• Focusing on 1 story at a time.

• Shipping working software.

The points that we have assigned tell the business, that’s what it takes to accomplish the job.

Over time you have a velocity for the team and you know, if these same people are writing great code at the levels they indicate with their point count, you’re able to predict everything with precision.

A business owner should utilize team velocity to manage things that need to be done on a software project.

Tools for Measuring Team Velocity

The way to manage team velocity in the software industry is to use project management tools.

Pivotal Tracker is a great tool. They have an iPhone app, an  iPad app, and a 3rd party desktop app for Mac.

With Pivotal Tracker, you can post photos of mock-ups and other tasks that need to be accomplished. You can also make comments and the business can participate, as well. These are just a few of the interactions that can go on inside the tickets produced with Pivotal Tracker.

When you put all your tickets in project management tools and then you go in your planning meetings, you’re basically ripping through all the tickets. And, as a team, you’re instantly assigning points.

There’s another tool called Sprint.ly which our mobile team was using, but just switched to Pivotal Tracker. These are just a couple of tools I have used throughout my years in developing software.

No Velocity Yet?

Sometimes when you get going on a new project, you need to start out with a velocity. I usually say, 10 points (based on Fibonacci) for each person on the team to get us going. After 3 weeks, we generally know the team velocity.

Another thing we have been doing recently is not assigning tickets to anyone, but leaving them blank and putting them in a bucket. When a pair is not busy with anything else, they can go in and grab a ticket from the bucket and get started on something new.

Any way you choose to do it, having a strategy and the project management tools in place will help you develop your teams velocity and drive your software development toward increased productivity.