Ever been setting up a project in TFS 2012+, started adding user stories (or PBIs, or Requirements) with estimates to the Product Backlog, turned on the forecasting tool, and started questioning your basic math skills? I have… The first time this happened in a live demo with a customer was really fun. I took a guess at what I thought was going on behind the scenes and luckily I guessed right :) Recently I got confirmation on what’s happening when another fellow TFS user asked the same question in the forums.
So, what on earth am I talking about? Check out the backlog below:
See it yet? If not, check out sprint 2. And yes, I know, it’s really odd that they use lines to separate sprints/iteration but the TITLE of the sprint is *above* the line. So Sprint 2 in this particular instance includes user stories D, E, and F. But notice that add up to 12 points and the forecasting tool is set to 10. WHAT?! But, but, that doesn’t add up! You’re right, but the theory is that you don’t have enough story points assigned to the first sprint (note that user stories A, B, and C only add up to 8 points), and so the ASSUMPTION is that you’d pull in the first user story in sprint 2 at some point and start working on it during the end of Sprint 1, even though it’s not slated to be FINISHED in Sprint 1. Otherwise your team sits and twiddles their thumbs waiting for the next Sprint to start. Well, they DON’T really, but you get the point. So you get no credit for the item you started working on early in the Velocity chart, unless you actually drag it into Sprint 1, but now you’ve over-allocated yourself in Sprint 1 and will likely end up finishing that item in Sprint 2 anyway. That’s a whole different set of issues you’re bringing on yourself.
Note the same thing happens in Sprints 3 and 4, below. Yes, marvel at my AMAZING Paint skills ::snorts:: There are 20 story points between them, so basic math suggests that you can finish all of the items in 2 sprints, even if one of the user stories ends up straddling the line a bit. Whether or not you accept this is as a good practice is well, irrelevant for now since you can’t actually do anything about it. The tool works how it works. It doesn’t make the tool useless by any means, but it is something to definitely be aware of.
Hope that makes sense. Cleared up an annoying little mystery for me. Something else to consider is that the forecasting tool is not meant to be the only way to plan your work, maybe instead you’d rather use slack in your sprints to work on bug fixes, or refactoring, rather than pulling in work for the next sprint. I know, OMG agile purists heads are exploding. They’ll get over it. It largely depends on your process as to how you handle those situations in reality. So use the forecast tool as a GUIDE, not the hard and fast rule for planning work.