An important distinction between Agile and Waterfall methodologies is how far out you plan. In Waterfall, you need to plan out the entirety of the project. This approach works beautifully for known products of understood scope. But when a deliverable is complex or has many unanswerable questions, Waterfall tends to fall apart, because there’s no way to do a sufficient amount of planning.
On the other hand, Agile thrives when products are complex and filled with unanswerable questions. With an Agile approach, you plan for only the next iteration—usually just 2 weeks. Agile works not because it avoids planning (Sprint Planning is one of the critical ceremonies, after all), but because it constrains the amount of work that you try to plan.
The idea is to reduce the total scope of work to a well-defined set of user stories. Each user story gets an estimate; the estimation metric is called a Story Point.
It’s common for a team that’s switching from Waterfall to Agile to look at Story Points and conclude it is the same estimation process. Most Waterfall teams use hours to estimate how long a piece of work takes to do, and at first blush, Story Points seem to fit this same function.
But this is Agile, not Waterfall! We need to use a process that makes sense for what we want to achieve, and to be cognizant of our constraints.
Remember, we know the project is complex. We can’t fully wrap our minds around it. We know there are questions we don’t know answers to. Further, we know that when these two factors mix, there are a host of unknown unknowns—things we aren’t even aware we need to know about yet.
With so much uncertainty, estimating how many hours it will take to build a User Story turns out to be a waste of energy. We already know from Waterfall that these estimates tend to be terribly unreliable and not particularly useful when trying to actually measure capacity, allocation, or time.
Instead of hours, Story Points measure complexity. The more complex the User Story, the more Story Points we think it’s worth.
How do we know how complex something is? We don’t! It’s a vague gauge. That’s part of the trick. We’re trying to evaluate the many questions we don’t yet know how to answer, the processes we’ll have to create, the limits of the work we’re expected to do, and anything else required to deliver the User Story.
Story Points, unlike hours, are an intentional measure of vagueness, because in Agile, vagueness is exactly what you’re trying to measure.
Naturally, two questions stem from this:
- How do we measure complexity when we know it’s vague?
- How does measuring something so vague help us to plan?
I’ll answer these questions in upcoming posts. In the meantime, remember that Story Points don’t measure how long something will take to do; they measure how complex it is.
