I find ProjectVelocity
to be a very useful tool for planning. However, I've had problems explaining it to my customers:
- I get asked, "Why can you only accomplish three ideal days in a ten day iteration?"
- Customers use velocity as a measure of productivity. I'm often pressured to increase velocity.
For me, both of these points are silly. On my projects (and I think many XP projects), velocity is the number of estimated
ideal days we accomplished in the last iteration. It incorporates all kinds of factors: estimate accuracy, productivity, and task difficulty. Our velocity is less than actual days because our estimates our always low. And I can't increase velocity, if no one is added to the project, without also increasing estimates across the board.
I've tried a couple of things to combat this.
- I've tried using "story points" or "gummi bears" rather than ideal days. Someone always slips and says "days" in a planning meeting, and then I get suspicious looks.
- I've tried just explaining the velocity concept. The customer looks at me with confusion and suspicion.
- I've tried applying our LoadFactor and working directly with man-days rather than velocity. This actually worked great, but I haven't tried it since LoadFactor was deprecated.
I would really like to just work with velocity and ideal days. It's such a nice, simple, accurate
technique. How can I get the customers to understand?
Perhaps call the Customer in for an all-day meeting, and start by telling this this is an Ideal Day meeting - that means no cellphone calls, no smoke breaks, no long lunches, etc. You're there to meet, not anything else. Then s/he may see what you mean by and Ideal Day - one without interruptions, without cruft; this may prompt the understanding that it is not a calendar day?
Also, don't slip with the "points" terminology. It helps to get everyone to estimate without thinking of points. I frequently get guys asking "so how many days to a point?" to which I reply "it doesn't matter... is the current task more or less complicated than this 1-point task?". Point out to your customer that velocity is a measurement. To ask you to increase it is like asking you to increase the measured distance of a long-jump. All you can do is try to jump further next time...
There is a closely related planning technique in ScrumProcess
which is worth taking a look at. Instead of using velocity or load factor, you simply graph 'work remaining' on the y-axis vs. elapsed time (days) on the x-axis. The equivalent to an iteration in Scrum is called a 'sprint', which is about 30 days. Pieces of work are re-estimated continuously as they are worked on by developers. The graph should eventually stabilize around halfway through the sprint, and you should be able to estimate the x-intercept based on the slope of the line. If the x-intercept is pretty close to 30 days (one sprint), then everything is going fine and you continue working. If the x-intercept is too far beyond 30, you might need to cut out some scope for the current sprint in order to make the 30 day mark. If, rarely, the x-intercept is well-below 30, you might consider adding a few features to the sprint to beef up the sprint and keep it around 30 days.
There is a good chapter explaining this in the ScrumBook
, in chapter 4, specifically section 4.3 Empirical Management and section 4.4 Managing a Sprint (pages 68-80).
The beauty of this approach is that 'work remaining' can be in any units (the ScrumBook
uses 'estimated hours', but it could be IdealDays?
, gummi bears, jelly beans, whatever). The only thing that matters is that the x-intercept should aim for 30 days. In all other respects, this is a very similar approach to XPs PlanningGame
, with the exception that it might be perceived with more clarity by the customer. Another thing is that, as an estimation tool, it scales to any size of iteration: estimate the sprint using 30 one-day iterations, estimate the entire project using 'x' thirty-day iterations (where 'x' is determined by the customer's budget/schedule).
I was going to suggest to our lot that we each pick a number in, say, (0.7 3.5) and make sure we each multiply all our estimates by our own constant before stating estimates in "days". The boss (aka. PoxyCustomer?
) has given up on velocity, you see, and seems to expect a 1:1 ratio.
In brief, I suppose, instead of "call it by another name to make it not a day", you could "make it not a day by changing it". Dimensional consistency prevents more imaginative shifts, e.g. to tomatoes.
Somehow though I can't see this flying. -- green/blue+red/black hats
An analogy might help. Ask your customer how long it will take to commute to the office tomorrow morning. They might say "on a typical day, 35 minutes, on a bad day maybe an hour, or if things are really great, 25 minutes." The time it will take to get to the office is affected by unforeseen circumstances – you realise you need to fill up on the way – there was a broken down vehicle causing a jam, and so on. Velocity takes into account unforeseen circumstances and other day-to-day commitments.