I was called into a meeting with a team here in the office a couple weeks ago because they told me they had a “question” about the estimations that they were doing. As we started talking, it became immediately apparent what the problem was, they were getting into arguments about whether their estimates were “too big!” Apparently, someone had told them that they “couldn’t” have any stories that were above a certain value, or at least that’s how they took the directions they were given. I stopped them for a minute and had a quick discussion about the reasons why we estimate stories, and why it’s incredibly important for the story points to reflect the size the team thinks the work is, regardless of what other people “want” them to do. I walked away to leave them to their work, and was entirely unsurprised when I saw some 20-pointers land on the backlog. Far too many teams suffer from some malady similar to that of this team — they forget why we’re asking them to estimate, so they start to engage in anti-patterns that undercut the very purpose for which estimation exists. In a follow-up conversation with another member of our Product Team, I started to think about how to describe Story Points as something other than “estimates” — and I came up with the idea of them as a “signalling tool”…
What’s the Point of Story Points, Anyway?
The first thing to think about whenever we’re talking about Story Points is the most fundamental question — why? And while that seems simple, it’s really not — and it’s where most organizations and teams struggle, because they really don’t get the “why” and just jump straight to the “what”. But that’s the path that leads to frustration and misunderstandings. So, let’s make it clear — story points are not about “estimation” as we traditionally view it. It’s not about having some accurate assessment of precisely how long it’s going to take to do something. We know that doesn’t work — people are inherently terrible at providing precise estimates of work that they haven’t started yet. And if we’re truly Agile, we embrace this unknown and use tools that we have to assess and plan that in — which is where Story Points come in. In an ideal world, the Story Point estimation that a team comes up with should be a combination of the known work that they understand, the unknown work that they can predict will come in, the “unknown unknowns” that inevitably crop up, and all of the polish needed to take whatever it is they’re thinking about from idea to execution to market. When we do measure Story Points as a metric, we do so as an average amount (velocity) — never as a discrete measurement at a point in time. Because Story Points are wrong as often as they are right (if you’re doing them right), and it’s only across time that we can see and level out the outliers.
The Points Tell a Story
When used correctly, the points themselves tell a story, as do the discussions that are had when the Story Points are being assigned. They’re telling us how confident the team is in what you’re asking them to do. They’re telling us what’s small enough to work on right now, and what’s too big to take on in a single chunk. They’re telling us when we haven’t done our own due diligence as Product Managers, or when the team feels that they need to spend more time thinking about the solution. If a team shortcuts the process of assigning Story Points to work that they’re being asked to take on, they’re undercutting everyone involved. If “nothing can be bigger than a 13” then you have no way of understanding whether that 13 is really a 13, or whether it’s a 40 masquerading as a 13. It provides — at best — a Cliff’s Notes version of the overall story, without any real understanding. As Product Managers, we need to encourage our teams to use Story Points as a tool to signal to us what they need in order to be successful — if the story’s too big, then it’s too big; it’s our job to figure out how to make that number smaller, not to push the team to do more work in a fixed amount of time with a fixed amount of resources. We need to enable our teams to tell us their story, and not the story that they think we want to hear!
Understanding Leads to Improvement
The bottom line is that understanding the proper use of Story Points in an Agile development process is essential to ensuring that we’re improving — which is the fundamental goal of both Lean and Agile. We need to enable our teams, not limit them — we need to think about the underlying use that we put our tools to, and ensure that those tools are actually being used to their full extent. When we set limits on how “big” a story can be, when we tell teams that they “must” do X amount of work in a sprint, when we set a deadline and make our teams work toward it at all costs, we’re not living up to the promise that we make ourselves when we call ourselves “agile”. Instead, we’re following the same anti-patterns that built the monoliths that Agile was originally aimed at dismantling. We’re regressing to past, bad behaviors rather than pushing forward to better and stronger teams. And sometimes that means taking a step back — or having our teams take a step back — and reminding ourselves why we’re doing what we’re doing. It’s amazing what just a little pause for perspective can do to change things for the better.
