One of the fundamental aspects of Scrum is to organise work into user stories to which the team collectively assigns complexity points. From this, the team’s sprint velocity can be determined and this in turn aids the ability to estimate how much work can be completed within each sprint and, therefore, how many sprints will be required to deliver all of the product features required.
But how easy it is to corrupt this simple and elegant method. No sooner does a business have a number to latch on to – namely, the velocity – then it uses this one and only metric to bash the team over the head. I have encountered situations where the managers are dismayed with how their company is using Scrum and want someone to sort it out: how can we squeeze them to increase the velocity? If that team’s velocity is 120, how come this team’s is only 65? If their velocity was 90 last time, how come it was only 70 this time? They will have to work overtime to make up those “missing” 20 points!
Anyone with an understanding of the philosophy of Scrum will know that these questions show a complete ignorance of that philosophy. Firstly, a velocity is an empirical description of work accomplished, not a judgement. Secondly, velocity is based on the relative points that the team itself has come up with and therefore has absolutely nothing to do with the points of another team. Thirdly, the idea of squeezing a team, or forcing them to make up for “missing” points is an outrageous display of command and control, completely contrary to the self-organising principle.
An unfortunate consequence of the controlling bosses with their clumsy and simplistic metric monitoring is the reaction by the team to try to buffer their complexity points. This would not matter in a good Agile environment because it would just lead to a kind of complexity point inflation and the team velocity would be adjusted accordingly, but with ranting bosses hovering around it really makes things look even worse.
On top of that, Scrum teams are often desperate to equate complexity points to time at a micro level: 5 points equals half a day, etc. Again this is corrupting, because it is the abstract quality of complexity points which rescues teams from bad time estimates. The moment you think of a complexity point as a unit of time is the moment that confusion ensues, because the estimate against time is invariably wrong.
How to get away from this unfortunate mess? Needless to say, ScrumMasters and Agile Coaches need to be courageous and get the controlling bosses to back off and to explain to them in no uncertain terms that they are completely violating Agile principles. But another thought which occurred to me was the need to make complexity points even more abstract and disconnected from time. Using Fibonacci points for example, complexity and time easily get conflated, as do size and time when using clothes sizes or dog sizes.
But what about “scary points”? Usually when we think of a feature that needs to be developed, the first thing that hits me is whether it is scary or not. It’s a real deep gut instinct. A feeling of “oh my God!” for scary features or a “sure!” for things that don’t scare me at all. One might contend that scary points could just as easily be conflated with time, but I have a feeling that it would be less likely simply because it seems to me that scary points take the assigning of points to user stories to a deeper level of subjectivity and gut intuition thereby helping to safeguard them from corruption.
