How to Control Digital Projects Using Velocity (Uses and Abuses)
Controlling Digital Projects Using Velocity - Uses and Abuses
No matter what most people who are charging by the day may try to tell you, Agile/Scrum is a pretty simple set of ideas - in its simplest form, three roles and four meetings. There is however one concept which is absolutely essential to get the most out of Agile which is very often misunderstood - velocity.
What is velocity? In its simplest form, velocity in an Agile project is a measure of how much work a team can get through in an iteration. How do you get that measure? Well at the beginning of each iteration an Agile team holds an iteration planning meeting. The aim of the meeting is to plan in a list of stories. Exactly what a story could and should be is different blog post, for now let's say as stroy is just a 'work item', something that seems to need doing by development team.
Estimation
In the iteration planning meeting, each story is given an estimate by the team. This is where it gets complicated. There are two different methods of estimating stories at this stage, both of which cause their own kind confusion. One way to provide an estimate is to ask the team how long it would take someone (or a pair if you're pair programming) to do this task if they had all the skills required and were not interrupted in any way. The number that the team give - 1 day, 2 days, half-a-day (that's normally the minimum estimate I'll allow) is then referred to as an estimate in ideal days.
Advantages of ideal days:
* Intuitive understanding of ideal days by the team makes it easy to get going with estimation.
Disadvatages of ideal days:
* Confusion of ideal days with real days by people outside the team cause all sorts of problems. The main confusion being the interpretation of ideal days as a promise from the team of how long a story will actually take.
There's another method which can be used, in which each of the stories that might be planned into the iteration is estimated in terms of complexity points. The team give each story a number indicating its complexity. For this to work, the team need a guide story that they all understand, or preferably a small group of stories that they all understand, that have all been given a complexity point rating. For example, let's say adding a login screen has already been given a score of 5 complexity points and the registration screen has been given a score of 20, where would adding space for adverts come? Is as complicated as registration? More complicated? The team might decide, having had bitter experience of dealing with third party advert providers that this is a 40 pointer.
Advantages of estimating using complexity points:
* Because these are abstract points there's less danger of them being confused with any real measure of time and so less danger of the confusion of an estimate with a promise of delivery.
Disadvantages of esitmating using complexity points:
* The very abstract nature of complexity points can be difficult to explain to the team. This can make them even more reluctant than they normally are to provide estimates.
* You've got almost no chance of explaining complexity points to someone outside the team.
wait an iteration and then count the velocity
Ok, so we've got through our iteration planning session, and we've put together a list of what we think we can do in one iteration (which will be very inaccurate if this really is our first iteration). Fast forward to the next iteration planning. This is where we calculate our velocity. We look at the list of things we planned and we count up the estimates on everything on that list that is done. That, ladies and gentleman is our velocity.
What is it?
Velocity in Agile is a measure of how much work can be done by a particular team on a particular project. That's it, it isn't a measure of how good or bad the team is.
What can it be used for?
Velocity has two main uses. The velocity of a team's previous iteration is used as a guide for how much work should be planned in the next iteration. A rolling average of the past 3 or 4 weeks is used to figure out how long it will take a team to get through a backlog of stories.
The velocity calculation
So, for example, you've got a backlog of 20 stories and the estimate for those 20 stories comes to 100 ideal days. You've got a team of two who are working in fornightly iterations. That mean that they're working 20 real days per iteration. But, iteration after iteration, when the estimates in ideal dauys of all the stories they've finished is added up, it comes to about 10 ideal days. So how long is it going to take this team with a velocity of 10 ideal days to get through a backlog which is estimated at 100 ideal days? That's right, 10 iterations.
Of course, in order to do that, the backlog of stories has to be estimated in the same units as velocity. If the team estimates in ideal days, the backlog needs to be measured in ideal days.
The Abuses
Someone once said, "what gets measured gets managed". In my experience what gets measured gets mangled, massaged and misunderstood.
Use velocity to set a target
Given a velocity of N, a genuine measure of the capacity of a team to do work, a manager might be tempted to declare that velocity in the next iteration will be two times N! From now on I decree that velocity will double every iteration.
Compare velocity between teams and projects
Team A's velocity is twice as high as team B's velocity? That must mean team B are a bunch of lazy sluggards. Actually, it could mean all sorts of things, it's not necessarily a problem of any kind at all. But it could be that there are all sorts of blockers to increasing velocity.
Confusing Ideal Days with Real Days
Team A 'only' did 10 ideal days of work in 20 real days, this means team A are a bunch of lazy sluggards.
Throwing your Rattle out of your Pram
I don't understand any of this new fangled Agile gibberish, all I understand is that you're saying I can't have my software until three months after I wanted it. So now I think it's time I called you some names to get that number down. First of all, do you realise how negative you're being? Surely if we all thought positively about this then the software would be written faster?
And anyway, I'd have thought that any professional team of software developers who knew what they were doing would be able to get this done in about half that time. But as I've mentioned to you before, your team is clearly a bunch of lazy sluggards.
The Uses
Remove Blockers
Pay attention to what comes out of team retrospectives. Are there any infrastructural or environmental problems that you could help solve, that could massively increase velocity. For example, more often than you'd expect, it turns out the team don't have enough computers, or there's something wrong with their setup. Use your influence to get blockers removed and fixed and velocity will go up. You will have a much better chance of getting your software on time.
Prioritise
Prioritise the things in your backlog. This is something that an Agile development team will be asking you to do. There are a bunch of ways of doing it. Kano analysis and Theme Scoring are the ones that I find most useful. Get together with other stakeholders - other people who really want to see this software and prioritise using one of the methods I've discussed. As a colleague of mine recently pointed out. Even if a set of items that are all the same priority, they still need to be done in a sequence. Why bother with all this prioritising and sequencing? So you can negotiate on scope.
Negotiate on Scope
So you want your project to deliver on time? Once you've done all you can to remove blockers, the only way that you can realistically increase the chance of a project delivering on time is to reduce the list of things that need to be done. If you've put some effort into prioritising the list of stuff that needs doing then this shouldn't be too difficult. What's important is that you remember that just because you don't get something by a deadline, doesn't mean that you won't get it very shortly afterwords.
posted by Mark Stringer @ 09:00
0 Comments
