Some problems with Scrum: do Story Points actually help?

Tom Breur

28 August 2016

Scrum is without a doubt the most widely adopted Agile approach. Yet many people who have been working with Agile the longest, seem rather critical of it. As much as I love Agile myself, I have some reservations, too. There are elements I like, but also some features that I struggle with. That doesn’t make it “unworkable” –I have seen it succeed– but there are weak spots that you need to be aware of, and cater to in a productive way. If you want to avoid many of the not-so-great implementations that have made me weary of Scrum, dealing with Story Points in a constructive way is a thorny issue.

Estimating & Story Points

Scrum implementations are renown for their reliance on planning and estimation, and measuring the “size” of stories in Story Points, even though the Scrum Guide 2106 doesn’t call for Story Points. That’s just the way it usually gets implemented. Time and time again, I see teams falling into the trap of celebrating increased velocity by a steady increase in Story Points they completed per Sprint. That is not to say that the team’s effectiveness might not have genuinely improved, but once “more story points” becomes the management holy grail… Guess what. If you are going to reward a team, in subtle ways, for ramping up their output in Story Points, you will get what you pay for: more Story Points. But will that mean more valuable software? There’s the rub.

The planning and estimation part of the Sprint is another elephant in the room… All too often I have observed Product Owners “push” team members to increase their Sprint’s commitment. “Surely you smart guys should be able take on that little Story? Y’all know how important it is, can’t you do it for me?” That dynamic can easily lead to unattainable goals that hit you back by an accumulation of technical debt. I’ve also seen inflation of Story Points, where the same amount of work gets assigned ever more points, another dysfunctional illusion of progress. Agile is supposed to turn around the management dynamic where managers are now working to enable subordinates, rather than cracking their whip and imposing unreasonable demands. That inversion gets overturned by this unfortunate and counterproductive dynamic.

Story Points should make planning more reliable and output more predictable. That dynamic will grow trust, foster collaboration, and lead to a more productive dialogue between (senior) managers and the developers they rely on so heavily for their success. I have seen that happen, too, and that has made me such a big fan of Agile. However, because of the issues I just raised, the dynamic can twist either way. Story Points are elusive, and can easily take on a life of their own. That, I have found, is truly a dangerous feature of Scrum implementations. It takes courage and confidence, and a safe enough environment to raise these issues. But unless you bring them out into the open, several risks are lurking. Do you really want to expose yourself to those?