Many Scrum Teams make use of a team’s velocity to help in forecasting. TFS provides just such a feature but beware – the results from TFS Forecasting can be misleading for the unwary.

Introduction

Microsoft TFS is a great tool for managing software projects, including those that use the Scrum framework. Out of the box, it provides Team Web Access which is a browser based tool that makes managing parts of the project easy for anyone involved.

One piece of functionality you can use in Team Web Access includes the ability to forecast when product backlog items may be delivered. Very handy. It makes use of the Scrum team’s velocity figure and the estimate provided for upcoming product backlog items to give a visual cue for the sprint in which an item will be delivered.

But results can be … bizarre!

If you want to follow along with this article, you may wish to download and use the Visual Studio 2012 ALM Virtual Machine.

Example of TFS Forecasting

1. Firstly, you’ll need to ensure that you have forecasting switched on.
2. The velocity figure is set to 10 in the demo (but you can change this. Just click on the number and edit in-place)
3. The product backlog items forecast to be completed within a sprint are shown below the line. In the example for Sprint 4, that’s the two highlighted items

So, we can see that with a velocity of 10, we’re forecasting the completion of 11 story points in Sprint 4, three story points in Sprint 5 and 52 story points in sprint 6. Seem strange? Let’s examine this.

Remembering that velocity is just a guide, I can understand why we might forecast 11 story points for sprint 4. I can also understand why we would not take 19 story points in to sprint 5. But I cannot understand why we are forecasting 52 story points for sprint 6.

The answer, of course, is that we’re not forecasting 52 story points for sprint 6. It’s simply that TFS doesn’t know where to draw the line. Why? Because we haven’t declared any sprints in TFS, beyond sprint 6.

So, here’s my first piece of advice:

Adjusting the Velocity

Let’s see what happens when we adjust the velocity up to 11. Just click on the current velocity number, enter 11 and tab out. Here’s what we see.

We’re now forecasting 14 story points for sprint 4. This seems strange. We could have taken in exactly 11 story points but for some reason, TFS seems to want to pull in more.

But sprint 5 is even more bizarre. It’s now forecasting that we’ll complete 52 story points. As for sprint 6, nowhere to be seen.

I decided to play around with the velocity number. I discovered, for example, that with a velocity of 13, TFS would forecast as much as 16 story points, but not 20. With a velocity of 14, TFS would forecast up to 20 story points. Finally, with a velocity of 16, TFS would forecast anywhere between 6 and 20 but not as far as 22 story points. This leads to my next tip:

Your Algorithm Isn’t My Algorithm

In the prior image, I have a suspicion that it’s the story with an estimate of 16 that may be causing some problems as regards the missing Sprint 6. So I played around with some different numbers.

Once I got up to a velocity of 13, I found that sprint 5 would contain a single product backlog item of 16 story points and sprint 6 would appear again (albeit with a total of 36 story points – see tip 1 above).

So, it seems that TFS truly is using velocity only as a guide. This may, understandably, cause you to be unsettled as to the basis of the forecast. After all, TFS is using it’s own internal algorithm to forecast what might be done in future sprints, not yours. Which leads me to my next tip:

In the example, we have a total of 66 story points (ignore the 8 story points in the Iteration Path ‘FabrikamFiberRelease 1Sprint 3’).  If we have a velocity of 10, that’s roughly 6.6 sprints from now.  If we have a velocity of 20, that’s roughly 3.3 sprints from now and so on. Check that against the forecast that TFS provides as a sanity check.

Size is Everything

But you know, the real reason that TFS forecasting is having issues is because of a problem with the size of the product backlog items. With a velocity of 10, two of the items are too large to fit within a sprint. This isn’t only a problem for TFS, it’s a problem for scrum teams, too.

Whenever I’m working with scrum teams, I usually advise that they bring between five and fifteen product backlog items in to a sprint. With a velocity of 10, that means that items should be sized between 1 and 2 story points on average.

To prove the point, I went into the demo and re-sized some of the product backlog items, keeping them within the range of two to four story points (please don’t try this in the office 🙂 ). Here’s the result:

As expected, this hangs together much better and makes sense. With a velocity of ten, we’re forecasting 11 story points for sprint 4, nine story points for sprint 5 and completion of the work within sprint 6.

So, here’s my next tip:

Note that this tip applies both to TFS forecasting and manual forecasting! But note that there’s a small sting in the tail here.

Good Scrum practice requires us to only devote time to product backlog refinement when that item is likely to be done in the next sprint or two. We don’t waste time on getting the detail on later items because they may never be done.

This invariably means that many of the later product backlog items will be of a large size and, as a consequence, forecasting will be flawed. This is a fact and leads to my next tip:

I suggest that you only use forecasting to help decide on the work for the next two to three sprints. Anything further in the future than that should be considered part of a product roadmap.

In Summary

Here again are my five tips for TFS forecasting:

1. Check you’ve declared enough future sprints to forecast product backlog completion
2. Don’t accept the TFS forecast blindly. Check it manually
3. Use simple maths to gain confidence in the TFS forecast
4. Be circumspect about any forecast where the size of a product backlog item is near to, or greater than, team velocity
5. The further you go in to the future, the less reliable your forecast becomes

Thanks for reading. I do hope this article has been useful to you. If you think anyone else may also find it useful, can I please ask you to make use of your favourite social media and spread the word. My sincere thanks in advance.