Customers And Velocity

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?

--JimLittle

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? --PeteHardie

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.

--MichaelHanks