With the points-mini-series still fresh in the mind now seems a good time to say publicly something which I’ve been saying privately for a long time.
Avoid points based contracts. i.e. don’t outsource work, or undertake work, on the basis of points – be they story points, abstract points, nebulous units of time or any other name you give them.
I have one client at the moment who wants their software supplier to sign a points based contract, I’ve advised against it. Another client is trying to sell points based contracts to their clients, while they are having some success – I think they rushed in before they had enough data to understand the implications.
Why do I say this? Well three reasons
First is Goodhart’s Law: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” Put it another way: any measurement metric will change behaviour once it is used for control.
In this context it means: points are very good at measuring story size and team velocity, they can be accurate at predicting when a piece of work will be done. But, if you use them for other purposes – like regulating a contract and making payments – they will change their behaviour. They won’t be so useful for predicting end dates, or for controlling contracts for that matter.
This is a problem many readers will be familiar with from traditional time estimation. Estimates are nominally sought to determine how long a piece or work will take, and thus how much it will cost. But they are also used as a means of targeting and for control. They are used as a proxy for commitment and they are gamed (i.e. changed for specific ends) when they don’t give the time/cost numbers desired. (This is something Esther Derby discusses recently in her blog, Estimating is often helpful, estimates are not.)
In fact, time estimates show the same range of problems present in the corporate budgeting processes and which has given rise to the beyond budgeting movement.
One direct result of Goodhart’s Law in this context is…
Inflation, the second reason to avoid points based contracts: points are subjective, they are not grounded in time, complexity, function point analysis, lines of code or any other objective measurement. They are in fact like a fiat currency: they are worth what you can buy with it. If people don’t believe in it, or believe the value will change then it will change. Check out rational expectations theory if you want to understand why.
Overtime points can devalue with the result that point scores increase. Actually, I believe the free floating nature of points is one of the strongest reasons for using them but in terms of signing a contract it makes them useless.
Most teams I see work in low points: 1, 2, maybe a 5, rarely an 8, they score 10, 12 or maybe 20 an iteration. One team I saw worked in tens, and scored hundreds each iteration. It was like one of those old Space Invaders machines were the last digit was a hard coded “0”.
The team’s project manager finished planning meetings with an call for the team to work harder next iteration, to reclaim the lost time. Iteration on iteration velocity increased. Inflation was rampant.
Finally there is practicality. As the recent posts from myself and Vasco Duarte demonstrate points, there is still a lot of debate over points. Personally I have come to the conclusion that exactly how you run iterations and count points makes a big difference. While if you agree with Duarte you might as well dispense with points and sign story based contracts.
Then there is the team: only the team which will do the work can accurately say how many points a piece of work will, or did, take; and then only when they have experience of doing the work. So you shouldn’t sign a points based contract unless you have the team in place and they have done some of the work.
Even a relaxed interpretation of that last point should lead you to conclude you should only sign a points based contract when the team is experienced in using points and you have historical data. If you feel you must sign a points based contract then only do it when you have data.
Still, I’d rather you didn’t do it in the first place.