Read the original Dutch post.
How often do we need to hash it out as Scrum practitioners that you shouldn’t translate story points into hourly estimates? Well, often enough to make me wonder whether there isn’t something inherently fishy about this obsession with numbers. Should you now feel the urge to wield the Scrum bible and explain what it says about story points and velocity: the 2020 edition still makes no mention of these concepts. Surprised? The developers who are doing the work are responsible for the sizing is the closest match. Alternatively, there are eighteen variations on the root of adapt-: adaptability, adaptative and adaptation. More than anything the guide stresses value and values: the value that the product represents to stakeholders and end-users, and the values that we should commit to in order to make the process a success.

The added value of a software increment is easy to express in a figure if it directly translates in increased revenue or reduced cost. But it’s never that straightforward. How do you value a better user experience, better service, attractive design, let alone a combination of all these? You can’t, at least not within a single increment. Consider the ways you can reward the people creating that value with more than just a pay check. Is there value in better equipment and more modern technologies when the end user does not see it? How about humane working conditions, instead of an annual death march to make it to the Christmas shipping deadline. The debacle with Cyberpunk 2077 has shown that it is hard to make good on your promise of the coolest game ever, and very easy to ruin your reputation with a shoddy first release.

Even the most data-centric, bottom-line loving CFO must admit that making software is about optimising value in the long run, which is too vague for comfort in an industry born out of hard science, whose daily practice is more art than science. Even the relationship between effort spent and value produced is unreliably proportional. You can sometimes delight the customer by fixing a crucial bug in an hour and next time lose all that credit on settling your overdue technical debt bill. In my IT-comedy Fair Trade the exasperated über-nerd tries to explain the manager who wants to add more manpower: “Software is something you create with your head, not with your hands. We’re not peeling shrimps.” With twice the available manpower you can peel twice the amount of shrimps, which will double your revenue.

Discussions about story points are not pointless, because we need them to give us a realistic idea about relative task size. Only then can a product owner determine whether the effort justifies the expected value delivered. This should be her prerogative, not the developers’. Story points in themselves are never an expression of that value and also for utilitarian reasons we should not be too attached to them. For if you are too bent on burning a stable number of points each sprint, they will eventually resemble a pretty reliable hourly estimate. “So you spent 400 hours last sprint and released forty points’ worth of stories? Let me do the math… that’s ten hours per point”. Now you try and convince me that those points are still relative.

I am even less enamoured of the concept of velocity. I consider it a bad example of the already dubious belief that all measurements must lead to improved knowledge – apparently there’s no English equivalent of the concise Dutch saying meten is weten (to measure is to know). What does it teach us if a team arrives at a stable velocity? That they have got better at predicting their output? Or have they just learned always to err on the side of caution with their commitment, in line with the old salesman’s adage: always under-promise to over-deliver? Whatever it is, it still does not say anything about the value delivered, only about the effort spent. Estimating the value is an intuitive process that takes a holistic approach and a good product owner is invaluable to that process.