Mr Metrics: Starting out with agile… What to measure and why?
Before we get started
If you’re reading this, you may have already read my previous blog. You may be looking at transitioning to agile, have just started, or have been ‘doing’ agile for a while.
Wherever you are on your agile journey, I’m going to assume you know what story points are and understand the estimation process, but if you don’t there’s a great blog here by Mike Cohn from Mountain Goat Software.
What is velocity?
Very, very briefly, it’s the pace in which your teams work. Actually, it’s no more complicated than that!
Let’s say you bring five stories into sprint totalling 30 story points, and you complete them all before the sprint closes. Congratulations, your velocity (for that sprint) is 30!
Why is this important?
Well, there are a few reasons:
1. If you have a stable delivery team (and you want a stable delivery team), your velocity will give an indication of how your team is performing. Ideally, your velocity sprint-on-sprint should be stable or improve slightly over time. If you have a stable velocity of 30 and in one sprint it dips down to 20, you know something went wrong and you need to do some investigating. The cause may not be in the team but regardless, you still need to understand why.
2. It will help with planning and forecasting. Understanding your teams’ velocity will help you forecast when you’ll be able to release a piece of software. If you have a project which has been estimated at 90 points and you have a velocity of 30, you know it’ll take three sprints to deliver.
3. A stable velocity will give your stakeholders more confidence in your ability to deliver. If you’re just starting out with agile, you’ve probably got some nervous stakeholders, who are used to being given fixed delivery dates and you’re probably trying to move away from this. If your velocity is stable, your delivery team becomes much more predictable and whilst you still may not want to commit to an exact date, you’ll be able to commit to a smaller and smaller delivery window. The more you’re able to hit these windows, the easier the conversations with stakeholders become.
So now you have some data…
I manage two delivery teams. One is new (Agents of Shield), the other (Goonies) has been established for a while.
Here’s Goonies’ velocity:
Let me cover the obvious point: What was going on between July and October? During this time, we were completing a long-running project where all stories were well known, small and refined, as well as having more team members which increased overall output. As that project wound down, team members were re-assigned back to other teams.
Since November the team has been stable and so has the velocity. Great!
Onto Agents of Shield. The team has been running for four sprints now and the velocity looks a bit like this:
Banter aside, this is what the velocity actually looks like:
Not too different from the rollercoaster right?
Let me cover the peaks first. As a new team (made of up from team members who had already worked in the company) we could only guess our potential velocity, so we gave it a ‘finger in the air’ approach, based on our collective experience. In retrospect, the November and January sprints were probably a bit too ambitious while we tried to to prove ourselves. Yes, we did get the work done and all the right quality measures, but it was close and we hadn’t left any room for support work or production fixes etc. My advice to myself those few months back, start smaller!
Now to the troughs. Ahead of the December sprint, the team were busy refining two initiatives. Between both changes, there was plenty of work to keep the team busy. However, just before the sprint one of the changes was pulled. Our three month backlog was unstable, which left the team with just a small amount of refined work to pull into the sprint.
Now to tackle February. During December, a change came through ready for our discovery phase. We quickly found out that whilst the ‘what do we want to do?’ was well known and had already been trialled in production, the ‘where are we now?’ was not, and we couldn’t progress this change with the right quality without understanding this. Collectively we decided to use the February sprint for further discovery and will now be moving back into iterative delivery of a change which will span 3 — 4 sprints.
Now for the important bit
You’ve looked at your velocity, understood the cause of any drops, time for action! In our case, we talked to our group of Product Owners and highlighted the impact of backlog instability. Since then we’ve had a stable backlog. We’re now looking at how we engage earlier with our Product Owners to shape their changes so they flow through our discovery phase better.
In summary…
Starting out with agile may feel like a bit of a rollercoaster and you might be tempted to give up and go back to old practices. My advice? Stick with it! Review where things aren’t working (inspect) and create a realistic action plan (adapt). Don’t try and tackle everything at once, as you’re almost guaranteed to fail. Pick little battles, get a few wins under your belt and then move onto the difficult stuff.
In my next article, I’ll be tackling Done vs Committed and some common problems it can highlight.
