Part 4: Points on the Scoreboard

I’ve mentioned Velocity a few times now along side this idea of “team capacity” or rate of delivery. That’s exactly what Velocity is. It’s simply a moving average of the total points delivered over the last 3 iterations.

Now in Tracker, you can tweak the finer points of how this works, but in short, this is the one metric that matters.

Scoring points for the current iteration is having stories Accepted. As you move from Iteration to Iteration, those totals on a per-iteration basis start to form a trend about your approximate rate of delivery. The moving average is a simple way to flatten out this over a long enough sampling of time to ignore weekends, etc, but a short enough window to show changes without too much delay. You can pull up the above Velocity chart in Tracker manually, but I’d encourage you to not obsess over it. Tracker knows what to do with it intuitively.

When is it going to happen?

POs want to know, managers want to know, PMs, stakeholders and developers want to know: When is story x going to happen?

The above image shows tracker taking a Velocity of 7 points and splitting up the Backlog into the (1 week) Iterations and showing the “planned delivery”, in points, for each iteration (red rectangle). Why are they not all 7? Because not every grouping of stories fits perfectly into your iteration’s predicted capacity. Trust Tracker - it knows what it’s doing. It also magically adjusts Velocity and planning if you tell it (in advance or retrospect) that some members have been off sick/away for a given week. It also let’s you cleverly adjust the Velocity in this mysterious “warping of time” fashion so you can see how much your team could do and by when, had the Velocity been greater or smaller for example.

Why is Velocity so important?

Tracker won’t work without it. The #agileforteams process won’t work without it. So unless you have some other more accurate and easy to apply technique for predicting delivery for software (which I haven’t yet seen in 10 years by the way) projects, you’re back to “finger in the air” estimating, missed deadlines, grumpy managers, depressed developers, high churn rates, micromanagement as a result of lack of delivery and all those other horrible things you’ve probably all seen at one time or another.

A stable Velocity is core to a “well oiled” Agile team. It becomes stable by keeping the inputs consistent. If you start with a new team, then you should only start trusting the Velocity after ~3 iterations of work. Also, if your team changes substantially in either members, or their regular weekly commitment to the project, then you will require another ~3 iterations of lead time before the Velocity is useful again. Yes, this does mean that the #agileforteams process requires a small “leap of faith”. But I’ll let the #smallbatches and getting working software very quickly into the hands of users do the talking for me. No one complains about receiving working software!

An Agile process needs to be sustainable

You’ve probably noticed by now that there is no notion of manual iteration planning (Sprint Planning in Scrum). This is because it’s just not necessary and in my opinion, a very dangerous activity. I’ve worked on teams where the Planning Meeting was fairly depressing most weeks. The reason is that most teams want to “push themselves” and plan slightly more than their Velocity. This most often sets an unattainable target and, unsurprisingly, the target is missed more weeks than it’s made. This creates a morale black hole and one I will avoid for the rest of my career if I have any say in it. Teams who deliver on their planned number of points were substantially more chipper and up-beat. You absolutely need to care about the morale of your team if you’re going to get their best work and a sustainable Velocity.

So let’s assume every member in your team is working as hard as they can all the time and be done with it. If this is the case, and I highly encourage you to assume that it is, then there is no need to plan iterations. Tracker takes this view also - we just take the next story off the top of the Backlog and Start it the moment the next developer has time. In this way, and using a moving average for Velocity which hides stories that roll over iteration boundaries, we have a clear and actionable delivery metric. Over time, if the team is consistent and respected, the Velocity will “flatten out” and this Velocity or capacity then becomes very powerful, enabling longer term planning. It’s not unreasonable then to take a large batch of stories and estimate them over an afternoon of pizza and snacks, and then use a 3-4 month timeline as a very reliable estimate. I’ve personally seen stable Velocities and a consistent team produce many months of estimates and deliver them with +/- 1 week. It’s almost a shame to call this “estimating” when the data can be so reliable.