Velocity Momentum: How to Make It Work for Project Planning and Management

In Softeq we’ve got quite a collection of idea men making a teamwork pretty Agile. Recently, we had a talk with our Delivery Manager, a Certified Scrum Professional Nadezhda Svirnovskaya. Here’s a summary of her insights on how to make an average velocity concept a powerful tool for your Agile team.

For an illustration of our argument, let us imagine several characters performing within a typical working environment. We’ve got a project manager, whose task is to make customers happy. Then we have a cool department manager juggling all the resources, and a customer in need of a particular solution. Finally, there certainly is a smart advice-giving guy, convinced that he’s capable of saving the planet. Let’s get started then!

The main goal of any PM is to deliver a project, whatever it is. However, as wise folks say, projects differ. In case it’s a Time and Materials, you’re just a lucky one: no need to worry about a thing, as the company simply gets money for the resources provided. Unfortunately, such cases occur rarely, as any customer wants to be completely aware of what he/she is going to pay for, and when he/she’s going to get it.

Let’s assume we’re out of luck. This is the case for fixed scope and time or a Fixed Price project within the iron triangle — that’s where project management takes the center stage. But before we get down to executing the project within the triple constraints triangle of time, scope and cost, we should first sell the project to a customer. Well, how to reach an agreement with the customer under fixed scope and time?

Project Scope: Treat Unconventionally

Let us apply the average velocity concept. Interpreting scope as not simply a pack of requirements we are going to fulfill, but an amount of story points, and having information about an average velocity along with that, we’ll easily estimate the release date. Or, otherwise, by analyzing the average velocity and release date inputs, we define the scope.

1^st Option

• Input: average velocity, release date
• Output: project scope

2^nd Option

• Input: average velocity, project scope
• Output: release date

By way of simple calculations, adding non-production overheads, etc. we finally reach an agreement. Doesn’t sound like a common situation. What’s the problem then?

Estimating Velocity: Success Denied?

What if we have no information on the average velocity whatsoever? Let’s have a look at where the problem springs from. There may be actually plenty of causes you have to deal with, such as the following ones:

• A completely new team
• A team with newcomers on board
• A new domain or technologies
• A new product owner

Whatever the case, you can’t rely on statistics. And that’s where our smart guy says: “Hey, kids, I’m going to help you. We’ll just make some calculations, and that’s it”. Here we start making forecasts, following a quick list of steps to arrive at the average velocity:

1. Assess the backlog at story points value

2. Determine the average capacity of the team by sprints

3. Start a mock planning session in order to get hour estimations that fit the capacity defined at the previous stage

4. Calculate the average sprint velocity

We may visualize it as the following:

Seems like the point where we sell the project. Indeed, unless we closely consider the cases when such a planning model does work. An ideal planning environment implies the following points:

• You've got the backlog
• The backlog estimation is accomplished by your team
• The mock planning session is carried out by your team
• Both zero and stabilization sprints are taken into account
• You use actual capacity, taking into account vacation and holidays if any, probable sick days, coffee/smoke breaks, etc.

Here’s an example of what a typical capacity assessment plan looks like:

Still, the projects that reach the end at this stage are few, as a frequent problem remains the absence of an established team itself.

“Designer Fakes”: Forming a Virtual Team and Mocking Sprint Execution

Within a large project requiring a resource pool of about 120 specialists, it would most likely be a problem to find so many people awaiting on the bench. What does our smart advice man think? Oh, that’s where he says: “Look, I’ve had enough of this. Sort it out yourself, ok?”

Within projects requiring from 80 to 120 people, we need a particular number of teams about the same size. The most appropriate solution here would be to take the following steps:

• Form a virtual team
• Consider those employed in other projects, but having a set of necessary skills, and borrow them for your project in order to make an estimation
• Set the delta

Seems like the very moment we get all our problems solved, and we are ready to sell the project. Now the time came, when we really get the management process started, struggling to keep within the project triangle constraints and make our customer happy.

Watch Velocity, Take Advantage

Once again, velocity management greatly assists at the stage. Why? While defining a project success determinants, we should admit, that the following points make a great deal of progress at the very beginning:

• A correct velocity assessment
• A correct definition of factors having impact on velocity

Bearing this in mind, a PM should take care to focus on the following activities:

• Tracking velocity changes
• Discovering the cause and source for velocity variation
• Managing velocity

Splitting Sprints: Turnkey Resources

As an illustration of the above-mentioned instructions’ use, let us consider the following example from practice. We’re working on a cool project with a dedicated team of a stable velocity. But at a certain point our department manager asks: “Hey, do me the favour to lend Peter. I give you John — he’s so good you’ll never regret”. Seems like impossible to refuse, isn’t it? The exchange accepted, and what happens next?

John joins the team and, therefore, needs time to get into the swing of things. As a result, we lose velocity.

If only you hadn’t agreed for the exchange… You just should have said that no one could replace Peter, providing the department manager with calculation proofs, and you definitely would keep up with the velocity required.

Another case: a product-owner comes in with the offer to employ CTI during the next sprint. Well, seems like it’s possible, as you’ve got Peter having the skill required, no matter he’s on vacation. Not to make customer uneasy, you take the risk of CTI — sink or swim.

So, the sprint begins. What are the team’s actions? They all start googling, making research, getting distracted from work in their struggles of CTI. Quite naturally, at the end of the sprint they fail not only with CTI, but with all tasks along as well.

The conclusion here is that there is a number of factors you are often unable to prevent, but should necessarily take into account. Next time during the short-term planning, you’d better suggest that CTI should be implemented within the 4^th sprint, when some Peter gets back from vacation.

How to take into account every single case of velocity lags? Just visualize it as we do below, and start gathering the stats on a regular basis.

Bringing to the Table Stats Delicacies

In our practice, apart from gathering velocity stats, we methodically collect data on the factors that influence velocity, putting it all down to the so called “deviations list”. It really works, especially within long-term projects employing many teams.

How do we use it? Well, it's quite simple, really. While planning a project, we consult the “deviations list” to make several variations of estimation: an optimistic forecast, a pessimistic, and a most likely one. Then, while creating a risk management plan, we’ll be able to consider all the risks thanks to the stats we’ve got. Here’s what it looks like:

Finally, we use the “deviations list” for short-term tasks as well. Say, in case we lose velocity, the document helps find out all the factors that can potentially give us the necessary increase. For instance, if we see that a weekly grooming enhances velocity by 3-5 story points on average when compared to the sprints without grooming, we can pick and use this point.