"Should we use Story Points?"

The previous weeks have born witness to a deluge of near-expletive-laden exchanges on various social media platforms between “agilists” fervently arguing about the use (or not) of “story points.”

For those unfamiliar, story points are units intended to enable a team to estimate, in a relative sense, how much effort an item of work (a user story) will require to complete.¹

The exchange of arguments could prove interesting and provocative. It could reveal important conceptual differences and evoke a truly valuable comparative analysis on subjects such as whether story points are useful or not, in what contexts and circumstances that might/might not be true, how story points relate to planning and shared mental models in teams, all kinds of things!

Unfortunately, this is the same argument that has been recirculating (like a broken record, like a broken record, like a broken record, like a broken record, like a broken record ~~ ) in the agile community since at least 2012!

And the back-and-forth is still conducted with the same basic argumentation. Nothing at all new. Just entrenched positions and dogmatic “…but do you know what person X says about that? They say…, and they would know…” (that last mechanism is a rhetorical device known as “appeal to authority,” meaning you should simply accept the validity of the argument based upon the alleged reputational or authoritative position of person making it, not the merits of the argument itself).

That last device (appeal to authority) is especially odious.

The pro/contra arguments typically emerge as some remix of the following: the pro-story-point side asserts the fundamental purpose of story points and how they support team estimation and velocity¹, the contra-story-points side asserts the reasons why story points don’t ensure the desired outcomes, velocity can be measured in other ways (or shouldn’t be measured at all), and around and around and around the arguers go.

Then it devolves into appeals to authority, quoting various “agile luminaries,” talks heard at agile conferences, and so on (all of which are relatively meaningless).

No one ever asks fundamental questions, like “in what circumstances would story points be useful?” “When might using story points or measuring velocity be harmful?” “Why??”

No time is devoted to understanding the types of work which teams face, or the challenges confronting their organizations as they seek to measure and improve performance or deliver outcomes.

Why not? Well, you’d have to ask them to be certain, but we certainly have a hypothesis: the majority of people advocating these approaches simply do not have access to any other frameworks, approaches, structures, methods, concepts, or ideas for how teams could or should operate.

Most of these individuals are adherents to a belief system and a cottage industry which exists primarily for its own purposes. Yes, it is dressed in the language of “helping teams and businesses build better products,” but if that were true, those individuals (and the consulting companies they lead or work under) would be far more interested in the actual challenges teams and companies face, as well as approaches appropriate for those problems. 

They would work hard to understand and reveal context, nuance, and leverage robust toolkits capable of responding to the complexities of organizational reality. They would not just argue endlessly from dogmatic, procedural standpoints about esoteric rules while appealing to industry-mythic authorities.

When you encounter these strongly entrenched mindsets as part of your search for help in improving your team and organizational ability to adapt, react/respond to change, and deliver, remember that the fountain of agility doesn’t spring from rigid, inflexible wells.

Also, in full disclosure and in the interests of transparency, we must admit that we have coached and led teams who have used story points exceedingly effectively, to the benefit of both the teams and their organizations. We have also coached and led teams who have not used story points at all. Those teams were also extremely effective at delivering results for themselves and their organizations.

"To story point, or not to story point? That is not the question." (Our apologies to Bill.)

So what does matter? What can you do to help teams and organizations?

1. Understand the context and environment in which the team operates. The way the team approaches the work should be dependent upon the context of the work and the constraints within which the team operates.
2. Leverage a framework like Cynefin to determine whether an agile methodology or framework is even consistent with the type of work the team is undertaking.
   • If you are unfamiliar with Cynefin, download our free primer on Cynefin.
   • If you are wondering whether you should adopt an agile methodology, check out our post "Do you need to adopt an Agile methodology like Scrum or SAFe?"
3. Focus on the actual drivers of team effectiveness (also discussed in the blog post above), the interactions of the team members, communication, and clarity of mission/intent/purpose from leadership.
4. Focus on the team lifecycle (effective planning, deliver, effective debriefing) and improve. Repeat. Repeat. Repeat.

As always, we’re here to help.

[1] When a team regularly uses story points to estimate the amount of effort their user stories will require, and they track how many of those user stories they deliver within a given time, they develop what agilists refer to as a “velocity.” Velocity is the amount of “story points” a team generally can deliver (on an average) within a given period of time (week, month, etc.). Measuring velocity enables the team to better predict (at least in a near term) when work will be delivered.