Points mean prizes!

BETA v01.00.61 - This is not official scrum guidance, it's all personal opinion drawn from my own experiences.

Velocity

Velocity is a scientific term that incorporates direction of travel as well as magnitude.

The velocity of an object is the rate of change of its position with respect to a frame of reference, and is a function of time.

This might explain why the group behind Scrum chose to 'Velocity' to represent a teams productivity and direction of travel from origin over a given time-frame.  The general public interpretation however is that it simply means 'speed', and that's perhaps one of the big misconceptions  ... Speed, or simply how fast an object is moving, is only half the picture.


The problems with velocity are compounded by misconceptions surrounding relative sizing, it's important that we know (the speed of) what we're measuring!

I'm hoping to relate my understanding of both these concepts in this post.

Highway to the danger zone...

I recall one team that got into quite considerable difficulty and on reflection I feel this was down to the issue of points and velocity being misunderstood. The team had all the elements needed for success;  an abundance of energy, skill, SMEs and stakeholder buy-in. Yet the journey, contrary to the very principles of scrum, was stressful, morale sapping, demotivating and unsustainable. And after all that pain, the most disruptive aspect was no working software.

As the teams new Scrum Master, I spent my early months surrounded by people who were mostly angry at Scrum; "This is entirely Scrums fault, scrum is rubbish". This was a bit worrying, my role as Scrum Master was to evangelise and facilitate a method that was openly and strongly criticised.  Was my new job already redundant, and how are we going reboot this when we're already so hugely invested.

Having worked in a few highly successful Scrum teams where energy and motivation was sustainably harnessed into delivering world-class working software, I have become a massive fan of Agile and Scrum. When done right it is simply an inspirational experience for everyone involved, and I wanted this team to enjoy that feeling.

The team was exhibiting a wide-spread of the typical symptoms of scrum dysfunction:

• No working software.
• Sliding release schedules.
• Multiple refactoring streams.
• High turn over of developers.
• High defect rate.
• No reviews or demonstration environments.
• Partially developed features. 
• All-day workshops, spanning multiple days.
• No working software.
• Lot's of competing factions had emerged within the team.

There was plenty of heat and smoke but the fire itself was hidden from view. The status reports, velocity, burn-downs and burn-ups all alluded to a highly successful team delivering on its goals sprint after sprint. But not one stakeholder had seen even a glimpse of a working product. To turn up the heat and pressure just a little more, marketing had run ahead of the team and were 'warming the market' in readiness to launch a product no-one has seen. The only demo I witnessed, with great fanfare and build-up, ended abruptly due to a corrupted database which resulted in some red-faced apologies. The PO was visibly flustered, the developers were embarrassed and the stakeholders looked underwhelmed; It was a not a room anyone wanted to be in. 

I was overwhelmed and disorientated, like I'd just woken to find my house was on fire. I had just one sprint to understand my new teams practices and I was failing to comprehend their complex rituals, rules, spreadsheets, practices and politics.  I recall being very anxious, to the point of insomnia, and it undermined my confidence in Scrum and my own capabilities. How had I been doing it wrong all these years? had my previous positive experiences been pure luck? Anxiety and stress consumed me, and it became a struggle to stay focused. I have to thank the developers who helped me through this period, without their support and professionalism, I don't think I would have seen this through to conclusion, but that's what good teams do! Together, we peeled back layer upon layer of complication, looked past the red-herrings, and eventually the root-cause came into view.

Their velocity and pointing strategy had been engineered to such a high-degree of precision, that paradoxically it had become detached and worthless and was slowly grinding them into the ground.

It had been decided that (points == time == money), and with this a complex series of instruments were devised to ensure that all three factors moved in synchronous lockstep. It was a well intentioned idea to simplify reporting and draw a direct comparison of progress versus spend, instead it inadvertently shrouded the product and team in an inescapable miasma.

Velocity is our team profit

Let's first take a look at what I think (stress that, think) velocity is, and how we should apply it.

I have a tendency to explain abstract concepts through real-world examples, every-day real-world examples. And when it comes to velocity, I find the analogy of profit to be a relatively good match, so let me know what you think... 

Velocity is a measure of economic progress, I often refer to it as the team's bottom-line. That which is left-over after all expenditure and operating costs has been deducted. e.g.

• Technical-Debt - Interest, loan repayment, short-cuts to a temporary solution
  Diverts productive resources away from delivering new value whilst repaying.

• Defects - Warranty repairs, investigations, fixing what we've already shipped, at our expense.
  Diverts productive resources away from delivering new value whilst fixing.

• Investment - CI, ops, tooling, skills, integrations
  Diverts productive resources away from delivering new value whilst we're improving ourselves.

• Process overheads - Meetings, workshops, performance reviews, travel, reporting, training, release cycles etc.
  Diverts productive resources away from delivering new value whilst we're talking amongst ourselves.

• Process maturity - Sizing consistency, product and customer knowledge, team cohesion
  Diverts productive resources away from delivering new value whilst we learn to work together.

So if you consider velocity as a measure of purely productive output, the net income from sales, after all deductions, you've now got something you can directly compare to your road-map and backlog, as a forecasting tool (Assume C.P.).

Bugs/TD/Tech-tasks, these are issues of an entirely different nature, these will eschew the velocity by incorporating points derived from a different scale of comparison.  Therefore, I encourage my teams to only point Stories, and Stories are strictly only solving real customer problems, delivering real customer value. Velocity therefore directly equates to productive output of customer value, the teams profit, and nothing else.

I have a separate post that goes into greater depth as to why I feel that only stories should be pointed. 

The velocity implicitly captures a teams overheads, as these are typically frequent distractions which serve to frustrate efforts and divert energy away from achieving the teams core purpose, delivering Stories, delivering real value. So if the team has a problem (process? tooling? people?), that's getting in the way of delivering Stories, then their velocity will suffer. The only way to increase a velocity, is to remove the problems holding it back. Velocity is a passive indicator, like a barometer, It's direction of travel is often more important than it's absolute value.

Back to the analogy of profit, when a business wants to increase profits, it can either get more efficient (eliminate waste), increase headcount, or a bit of both. Keeping an ever watchful eye on the profit for the crucial MC=MR tipping point. 

To me, it really is that simple, (output - costs) -> velocity.

When velocity is no longer a self-generating artefact, reflecting the teams productivity and direction of travel, it becomes worthless, in this instance it simply became another way of measuring time itself. Time as we experience it is constant, and so was our velocity. 

What are story points anyway?

The actual scrum practice of pointing is to merely provide a quick, low-cost estimation of a proposed Story, in keeping with the Agile manifesto of a preference for the regular drops of working software over process and documentation.

Story points are typically based upon the Fibonacci scale. as opposed to 1..10, in part I believe to disabuse people of any such notion of precision or linear progression, and to strongly assert the rapidly increasing uncertainties and risk as we progress along the scale.

It turns out humans are pretty poor at absolute estimates, but we are very good at comparing the relatively similar objects. The relative sizing technique embraces this human characteristic, and simply allows teams to make rapid, relative assessments of effort required.

How far is it to the moon?

1000 miles? A million? 10 million?

Well, I can tell you that its closer than Mars or Venus! 

Relative sizing wouldn't be ideal for the engineers at NASA, but we're not looking to plant a man on the moon, safely. We're using an averaged number (velocity) to forecast the delivery of fairly abstract pieces of work. And to that aim, Relative Sizing offers enough accuracy at very low cost, and enables the team to iterate rapidly and release often.

Each team will have a different perspective scale, which is why one teams 5 can be anothers 13. Just like the French might say, the moon is about 385,000Km and the Americans will say its about 240,000 miles. It's the same, just expressed on different scales. But would you say the French are going faster, further, just because they're measuring with KMs?

What matters is that any given team is consistent over the near-term with their sizing and scale, and that's how velocity, averaging out points delivered over a series of recent sprints, comes into its own. Ironing out peaks and troughs, it provides an accurate enough forecast of the teams future performance based upon its recent past.

Defying gravity

So, how does attaching $$$ to points, undermine the value of story points and velocity?

Principally, it takes a number out of context. It takes a number that was simply a relative position along a scale and converts it into a denomination of currency, who would do that?! :)

And with this, the humble velocity and its constituent story-points, became the key concern in any conversation.

• "How can a 13 become an 8,8,5 and a 3?"
• "How do we tell this to the board?"
• "That's not an 8, its a 5, it has to be a 5, otherwise it won't fit" 
• Let's point those defects as its work we're doing and it should show in our velocity
• If we freeze the backlog, then it means our budget isn't increasing
• An entire ecosystem of XL spreadsheets arrive to present different messages to different audiences.

The teams output was measured by points against budget, rather than working software meeting customers needs. 

The project was being driven and reported along the lines of achieving a set number of points per sprint, to tally up with the money spent. Estimation accuracy was, an amazing 98%, for sprints stretching over many weeks, involving upwards of 20 people. Velocity barely fluctuated from it's impressive 3-digit value, sprint on sprint. And yet, still no working software? 

The pressure was on the team to deliver the same number of points each sprint, as this is what was reported back, in terms of spend according to forecasts. This is where the pressure, IMHO undermined the team, and Scrum. 

• Abuses of scrum, transferred responsibility on to developers
• Pressure was on all individuals, to deliver a set amount of points. 
• Personal velocities were made known and individuals named and shamed in retrospectives
• This did not foster a culture of collaboration, in fact it served to isolate developers.

So, at a grass-roots level, the team adapted, they began developing coping strategies. One of which was to point everything. If they spent any time on it, it was pointed. 

• Work was completed without reasonable care or attention to detail. 
  We didn't deliver what was asked, but we took full payment anyway
• Rework was pointed 
  Then we charged the customer again, for delivering what they wanted in the first place
• Bugs were pointed
  Then we charged the customer again, for fixing-up already delivered work
• Tech-Debt was pointed
  Then we charged the customer again, to re-deliver the same thing, just differently

It was in effect, a carousel scheme, the same value proposition went around and around, repackaged under the guise of a new story, or fix, or TD, or refactor, and each time, the team got paid again and again and again.

And personal velocity targets were met, one way or another. Points were delivered in line with money spent, and everything looked rosy. And yet, there was still no sight of any working software. 

The gamification of scrum and relative sizing resulted in a form of systemic inflation, whereby points progressively delivered less and less customer value. Expectations we're continually dashed, all the while scope and quality was being cut to try and regain ground.