I was reading a post today on Glen Alleman’s Herding Cats where he talked about velocity as a vector and posed a question :
What is the purpose of a velocity, if you do not know the distance to the end?
I thought I’d give a quick answer and ramble on about other related thoughts along the way :).
I agree with Glen, measuring velocity does not replace planning and scheduling on agile project, rather, having a measure of velocity can facilitate those activities. However it all depends on how much planning (if any) you actually need and there is certainly a purpose to velocity besides knowing the distance to the end.
There are basically two types of agile projects you can be involved in.
- Deadline constrained – where you must deliver on a certain date and will include as many features as will fit.
- Feature constrained – where you must deliver a set of features and will keep going until all of them are built.
The first kind is a lot more common then the second and even in feature constrained project people often try to impose arbitrary deadline constraints (which may or may not be a good thing depending on the environment). Let us have a look at both types of projects and what role velocity can play.
Deadline Constrained
Having to deliver on a certain date can be highly stressful. You don’t know precisely what features are going to make it into the final release and you can’t really go live without a certain feature set. Some kind of measure of approximately how long the whole thing is likely to take and what features are likely to make it would be really handy. But, at the start of the project, velocity is not that measure, infact a good measure for this does not exist. People keep trying to find one but all likely candidates are wildly inaccurate (I present to you function point counting :)) and based on assumptions that will not hold throughout the lifetime of the project. However as you keep working on the project iteration by iteration, the team will estimate the stories and as the iterations are completed you will start to get a sense for the kind of velocity that the team can sustain. The velocity and estimation process will feed off each other to allow the team to estimate stories more accurately the further along the project gets; this in turn will allow you to set some expectations as to the velocity you’re likely to get in the next iteration and even roughly pen in the velocity for a subsequent iteration or two. Although it would be folly to try to extrapolate this toward the end of the project as you will have to assume that conditions will not change (i.e. team will always remain the same, noone gets sick, features won’t turn out to be more complex etc.) and this will never be the case.
So, we are not using the velocity to plan the lifetime of the project or the amount of features we are likely to deliver. Instead the team uses the velocity to get better at estimating the features and due to this you get more and more certainty as you go along regarding the likelihood of the team delivering what they say they will (you gain more confidence in your team). This type of project requires a lot of planning. You need to make sure you’re working to a realistic schedule, you need to build in slack based on inaccurate estimates, you will need to take into account risks and having done all this you will need to adjust all this stuff constantly as the estimates improve, team conditions change etc. Doing all of this can give you some indication regarding what is and will be happening with the project and this indication will be more and more accurate the further along the project gets. As you can tell velocity is part of all this and is a very useful tool/measure, but in this case you know the distance to the end (you will finish on a certain date), what if this was not the case.
Feature Constrained
Despite what you might believe some projects don’t really have a deadline. Ongoing products that are actively developed are all about features. Sure we try to deadline constrain these as well. But when the deadline is reached, we just go on building features trying to reach the next ‘arbitrary’ deadline. These kinds of projects potentially require a lot less planning. You don’t know the distance to the end, you just keep building features while there are features to be built. The only planning you really need to do for this one, you bring upon yourself by creating the ‘arbitrary’ deadlines in the first place. Why are they ‘arbitrary’? Well, presumably your team is keeping the system in a releasable state at the end of every iteration so, you could go live any time you want if you’re happy with the feature set, so any go-live deadlines must be arbitrary :).
We don’t know the distance to the end, does that mean velocity has no value in this case? Possibly in an ideal world of some sort that might be the case, but we live in the real world. I am going to contradict myself and say that the ‘arbitrary’ deadlines I was talking about before are not really arbitrary at all. As far as the team and the system is concerned they are not necessary but the business/customer is relying on the system and they need to do their own planning based on the kind of features and functionality they are likely to expect. Therefore they need to know what features will be available and when they will be available. This is why feature constrained projects end up with release deadlines of their own, and for this same reason velocity has just as much value for these projects. It helps the team improve their estimation and zero in more or less precisely on what sort of functionality (and how much) it can deliver in an iteration (or a set of iterations). And so velocity remains a valuable tool regardless of whether you know the distance to the end or not.
Of course if your team is not using a proper estimation process, if you don’t adjust estimates as you go, if you keep taking out and putting in people, if the team doesn’t commit to their estimates – velocity becomes a meaningless number. In this case, all it is good for is looking good on a BVC (big visible chart) or BAC (big-ass chart) as I like to call them :).
Images by lrargerich and psd