A different take on sprint velocity

Sprint velocity is an useful stats for any project or team. It can provide many useful information including:

1.  Teams throughput at the present
2.  How much team is likely to accomplish in next sprint and thereafter. Therefore it allows a planner to prepare a roadmap.
3.  What’s the trend:
4.          Past à is the team progressively doing better?
5.          Future à what’s the likely throughput over next quarter or half year and so on?

Following chart shows velocity of my current project sprint over about 9 months’ time period.

Figure 1

But simply using the velocity chart above has some inherent drawbacks. The output varied largely in every sprint. If  I just take simple average of all sprint that does not predict next sprint velocity. Its in fact 30% less than what my current sprint's output is. The result get's bit better if I take a moving average.
The reason behind this discrepancies are not random. There are some valid explanation for this. Simply taking average over a period of time and using that for future prediction is equivalent to working with ideal working condition. And as it said reality is always far from the ideal.
One of the most common of this variable is change in team. Over a period of time in evidently team member will change. Some people will leave. Few more will join. Leave could be temporary, where one of the team members may be loaned to another team for few months and will come back later. Whatever is the nature of the change, it will affect the velocity.

Second is the absence or holiday. All absence will affect sprint velocity.

Third is the length of the sprint. Scrum team normally works with an fixed sprint length  of 2, 4, 6 etc. weeks. This too changes for various reasons. Holidays, emergencies and  whatever unforeseen reason sprint length could change and do change.
Now that we know there are variables. How do we do to overcome this variable and get better result out of sprint velocity? Read on..

Effective Resource

First we need to calculate effective resource for a sprint. Following spreadsheet shows an example of such calculation.

Figure 2

For every sprint( possibly before or in sprint planning) note down all the available resources to the project. Then check
     Is  any resources are shared? to update commitment percentage accordingly.
     Have you got a new resource joined to the team? He will need to set up time or catchup time. Therefore to reflect that you need to change his or her commitment percentage.
     Is any one has planned holiday? Add that to non working days.
     Is there a holiday day in the sprint? deduct that from ideal sprint length to calculate current sprint length.

Once you have all of this data, you can calculate how much effective resource is committed to a ideal length of sprint.

Single Resource Velocity

Once you have effective resource of a sprint, you can calculate what the throughput/achievement of that resource on a given sprint. Tracking this throughput over multiple sprint will give single resource velocity. following chart shows single resource velocity of my project.

Figure 3

If we compare Figure 3 with Figure 1 we can see the variation has calmed down over later part of the chart. The trend line quite leaner. Therefore we can use this figures to calculate some of the stats that we are interested in regards to sprint velocity.

How do we use this data

Now the single resource velocity is change proof. The above calculation normalizes all the variance we have talked about. Therefore we can calculate/predict future sprint output much more correctly.

Simply calculate your effective resource availability.
Then multiply that with single resource average velocity ( better if you use moving average ).

To predict further future throughput ,we only have to know on an average how many resource will be available to he team.