Danger of Story points and recommended updates for the next edition of the Scrum guide

Many, of not most of the problems, which Scrum practitioners are currently sharing on social media, are rooted in one same issue: using the story points as the metrics to measure developers performance. Or using the story points to compare multiple team results in the scaled Scrum.

Or worse, they are using story points to distribute rewards among team members...

Use of story points as metrics creates problems with both, transparency and inspection; and in the long run can threaten actual increment of value, and success of the whole project.

The reason why this is happening, is because while story points are widespread among Scrum practitioners, and are even stamped into Jira, most popular Scrum software, many practitioners and associated managers simply don't understand what "the story points" actually are.

"Story points" and "user stories" were established as part of eXtreme Programming (XP) which is not directly connected to Scrum, and are only complimentary in the Scrum framework, with many Scrum founders advocating against excessive use of this techniques. Story points are not mentioned in a Scrum guide, and aren't even mentioned in the Scrum glossary; not a single guide, lesson, course at scrum.org mentions them. As a result many people use Story points without actually understanding them...

So what are those "story points", and why should Scrum practitioners be very careful with them?

To make long story short(relatively short), most important thing to remember is that story points are not metrics.

I repeat: STORY POINTS ARE NOT METRICS.

They don't correspond with any physical matter: size, volume, charge, data count, space or time.

They are relative, and not exact.

Story points are internal estimates of Scrum team. Team makes them for itself, when developers are forecasting upcoming work. This is where "story points" begin, and this is where they should end.

To help understand story points I usually employ following exercise.. Lets use my favorite model of Scrum team who is selling bracelets and earrings at the local artisan market ;) (please remember that Scrum can be used in any domain of life, not only IT)

First step is asking the team to estimate the task difficulty: which is a combination of time and effort. In the beginning developers do this estimates using "T shirt sizes method..."

Like S - small task, M-medium task, L-large task, XL is an extra large task.

For example: printing the necklace using 3 d printer or stamping it by a press is a Medium task or M, and hand carving it would be Extra Large task or XL...

Bringing the items to the market by car is a large task or L, and putting the items on the stall is Small task, or S

So during the Sprint, the backlog of this team would contain S task, few M tasks, one XL task.

Using this estimates, the developers(who develop the necklaces and earrings) can plan and inspect their own work during the sprint(lets say its two week cycle period when they develop new souvenirs, bring items to the market and collect customer feedback). This estimate and validation is an internal business of the team. And this internal inspection is the only actual use of the "T shirt size" like estimates(which are not metrics, obviously) .

So where is the place for the "story points" in this estimation process? Only reason why story points came out, and why they are numerical, and not letter based, is because many teams like to use burn down charts to validate own assumptions. And having numerical values at the vertical graph is handy.

If team wants to use cumulative flow diagram or burn down chart to see how the production and sale of above mentioned necklaces and earrings go, they might "convert" the "T shirt sizes" which I have presented above into numbers. Some Scrum team traditionally do it using Fibonacci scheme: like XXS and XS task would be 1, S will be 2, medium 3, ML would be 5, L would be 8, XL 13, and so on, breaking it on 20.

Assigning simply one-two-three numbers is possible to, if Scrum tradition of using Fibonacci sequence is to complicated for a team. Its up to the self managing team to decide.

And that's it about story points. Once team has changed the letter based "T shirt sizes" into numerical "story points" they will be having PBI(product backlog items) estimated in numbers, instead of letters. This means that Scrum team members are using story points from this moment on.

This is a particular moment when the risk of forgetting an actual origin of the numerical estimates kicks in. People naturally tend to associate the mathematical numbers with exact measures.  So, driven by the misconception that numbers should correspond with metrics, managers, CEO or even Scrum practitioners who don't understand the origin of story points begin to presume that story point numbers somehow represent the performance and result.

Unfortunate use of term "velocity", which is NOT SAME as velocity in physics makes this confusion even worse.

As mentioned bringing misleading and false metrics(which are not actually metrics) eventually causes problems in team transparency and inspection of results..

So, allow me to repeat, it is very important to remember that estimates are not a measure of teams actual performance in any way: because, of course it would be absurd to measure teams result based on teams own predictions... Which are in fact hunches, not even calculated forecasts.

It would be a same thing like setting business plan, or worse calculating performance results based on weather prediction which is made purely on folk omens.

Having said that, may be next edition of Scrum guide should contain some stronger provision, preventing use of estimates as the metrics for counting the results of the Scrum teams work . It should also stating, more clearly, that the value of increment is one and only aspect which is establishing commitment and result of the team.

Otherwise the story pointing issue might east Scrum within like a cancer.