When to ignore historical velocity

George Santayana once said:

    Those who cannot learn from history are doomed to repeat it.

This theme holds even when we are doing our estimations. One of the best ways to predict your velocity for the coming iterations is to simply look at the velocity that was attained in the past sprints.

More often than not, the method will prove itself as the most effective and efficient ways of making reasonable plans. But what about the less often times?

Nassem Taleb puts it beautifully:

    If the past, by bringing surprises, did not resemble the past previous to it (what I call the past's past), then why should our future resemble our current past?

So then it today’s entry we are going to explore some of those times that you may want to be a bit more awry of your historical records.

Change in team members

Scrum advocates for tightly neat team of specializing generalists. More generally, you want a jelled team working on your project no matter your chosen process. A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts (Tom Demarco).

Yet this process takes time. So when you have to add or change team members, be sure that it will take time for jelling to happen. As such you can expect a drop in velocity.

In addition you also consider the impact of ramp up time for the developer being onboarded.

Change of product owner

In a scrum team, the product owner is the individual or team that dictates the conditions of satisfaction and prioritizes the work to be done. You can think of them as the client’s representative in the team.

Although the product being developed is still the same, it would be naive to assume that different product owners will provide feedback with equal efficacy. As such when the client changes the product owner you should brace yourself for a change in velocity.

Change of estimation team

Each team member, including the product owner, have a role to play in coming up with the estimates. It is not always possible to have the team work on estimates, say if you have been asked to estimate a story to be developed in the future and the team is just not around.

While relative estimates tend to be consistent, they also carry a systematic bias. A systematic bias An inherent tendency of a measurement process to favor a particular outcome. Thankfully this bias is easy to correct but some observations are needed to determine the new velocity. Thus if a different team did the estimates the velocity is also likely to change.

Change in technology

The technology landscape changes faster and faster everyday. When a change in the outside technology factors inevitably hits you, then you can say goodbye to your previous estimates.

This change can come in multiple forms including:

  1. New developer tools
  2. Upgrade of service that your product depends on
  3. Change in industry protocols
  4. Upgrade of language version

etc

Organizational change

The development team is part of the ship that is the business. As the scrum master, you must keep your radar out for organizational politics. Anything that affects the livelihood of the team is likely to affect their productivity as well.

Even changes that may seem trivial such as being moved to a different office space can have adverse effects on productivity levels.

New project

It might seem obvious, but really a change in the project that the team is working on is likely to yield a different velocity from the historical one.

A similar project can give a feel of the size of a project, but that is it. Every project comes with its own people, requirements and other nuances that can not be ignored. So by all means use the estimates from previous projects for sanity checks but not as absolute guidelines.

Has your team ever experienced a change in velocity? What was the cause? Talk to me on my twitter @ jchex or on the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer