Article summary
Developers often talk about points in agile software development, about how they specifically aren’t measuring time, but complexity. But… is that true? If so, WHY is it true, and how did it become that way? Why does everyone care so much?
The classic way of developing software was known as the waterfall method. This model relied on extensive planning and rigid processes to provide structure for delivering results. This was the earliest methodology to gain popularity, due it its similarity to older physical manufacturing structures in that it gave a very cut and dry, step-by-step process for delivering a product. This meant leadership at a company could see a plan, track progress of the plan, and reliably “know” when it would be delivered. Sounds great!
Except…it wasn’t great. It turns out that software is super complicated and ever-changing. It’s impossible to know what problems you’re going to run into, or everything you’re going to want your software to do (and thus impossible to predict how long something is going to take), and no amount of planning can solve that problem. Software is more of a living product that is constantly evolving and ends up being built iteratively, by hook or by crook. This means waterfall always resulted in basically one of two failure conditions: you abandoned the plan partway through (meaning a huge portion of that planning time was wasted), or you followed through with it and delivered software that didn’t work or nobody actually wanted, since you didn’t pivot when learning new things, encountering new problems, or getting user feedback of what you’d built partway through.
Agile
This is where agile stepped in and defined a new way of operating. Agile, at its core, is about delivering value as quickly and efficiently as possible. You can read the agile manifesto in its entirety here, but really, that’s all it boils down to. It came into existence as an answer to the essentially non-functional waterfall method. It leans into being iterative, responding to change, researching what users want, etc.
This embraced a way of building software that was flexible and adaptable, and allowed delivering much more value more efficiently. However, this is a methodology, a new way of thinking, but it’s not a comprehensive framework for operating. How do we operate day to day to accomplish that? Also, something very important has been lost: predictability. What happened to our plan? Sure, we probably can’t know what we’ll be working on 6 months from now exactly, but we still need some indication of how long things will take, right?
Scrum
This is where the two common agile frameworks come into play: Scrum and Kanban. One of the primary goals of these frameworks is to allow agile implementation by real teams. This means they HAVE to have some way of giving basic predictability. For Kanban, this is simple: you break out work into stories that are all roughly the same size. This means predictability is just counting the number of stories in a feature. Note that this isn’t easy, just straightforward. This is typically considered much harder than Scrum, since breaking up all stories to be the same size is hard. It also takes a lot of time and effort from key stakeholders (including technical).
A much more popular method is Scrum. Instead of making all stories the same size, we add estimates to stories and define set time sprints. Before each sprint, we pack an appropriate number of estimated stories into it, and then we can mostly reliably complete that sprint. If we want to see farther out, we need more estimated stories (just as we’d need more broken-out stories in Kanban to do the same). Of course, nothing after the current sprint is guaranteed, since the goal is to be able to pivot as needed after every one, but it gives rough ideas.
Notice I didn’t mention what this estimate was, because honestly, it doesn’t technically matter. Any measure that allows accurately sizing stories so they can be compared would work here. We just need a way to put the correct amount of work into each sprint. So, of course, the first idea was time. It’s a default idea that’s been used forever, so why not here? It has some sense behind it, too, as Waterfall was measuring out far too much. If we break down chunks of work (stories) to be bite-sized, surely now we can accurately measure how long something will take, right?
Points
It turns out that, no, we still can’t. Or more accurately, we’re bad at it. Human brains are pattern-matching machines. We expertly take new information we’re given and predict results based on previous similar situations we’ve encountered. Problem is… humans suck at measuring time. How many times have you guessed how long it will take to clean out your garage, or run errands before meeting someone for something, and been wrong? So many little factors are involved in each step of this process, and all of them have these hidden time costs that are hard to remember and include in future predictions.
Unpredictability
To continue this analogy… some stories are like laundry, or dishes: a set process that’s been done a dozen times, and we know exactly how long it’ll take. But most… are more like your garage. It involves putting away dozens of things, and some number of them are going to have surprise complexities hard to consider when you’re staring at the whole pile of it from your garage door, until you start doing it and run into them.
So, that sounds disheartening. Now we have no predictability, blast you human brains!! But wait…what if we can measure time without relying on people to do the measuring? How, you say? Enter: POINTS. Let’s forget measuring absolute time for now and come back to it later. For now, we need to solve the immediate problem of packing a sprint with the appropriate amount of work, which means we need a relative scale to use for stories.
So what happens if we just skip all units completely and just use arbitrary numbers? It turns out…exactly what you’d expect. The numbers are weird at first, but after doing it for a bit, each team solidifies on some unique scale that makes no sense out of context, but does a pretty darn good job at comparing the relative size of one story to another. NOTE: this is why the mantra that points are complexity and NOT time gets repeated loudly and consistently. We don’t want to know how long you think it will take to clean this garage (because it will be wrong), we just want to know how much stuff is in this garage, so we can compare it to other garages, and end up with the right amount of total stuff in each sprint!
Data
Now that we have a good scale of relative size…how do we turn that into predictability? Well…we use data of course! We track how many points a team has completed in a sprint, over the course of multiple sprints, and then we simply use that as the points’ velocity. This has effectively turned those points into something you can measure on a real time scale (the length of the sprint). The thing to be careful about this is to note that this does NOT mean there is a direct translation from points to time. So you can’t just convert it and then have people start using it.
It’s important to remember that when you’re collecting data, keep the focus very narrow as to what it’s describing. Try to extrapolate it too far and there could easily be reasons that extrapolation isn’t true, but you can’t see them with the narrow data you’ve collected. For example, a team that consistently completes 20 points every sprint is not necessarily completing 5 points every quarter sprint. So you have no way of knowing if a five-point story takes a quarter sprint, or the whole sprint, or even two sprints. It may be that the team members are all finishing a five-point story every other sprint. Since velocity is an average, there’s no way of knowing. Other metrics can help answer those questions, just pointing out a danger in relating values without sufficient care.
Tying it together
There are a lot of oversimplifications and gaps in the general history in this article, but I went over it briefly to hopefully give context as to why points came into existence, and why it’s such a big deal. It’s just really hard to plan projects and track time and get any kind of predictability. A lot of work has gone into systems to be able to do so without being overly rigid and time-consuming, and they have gained a lot of popularity. Time estimates will simply never be accurate, so the best you could do is to translate developer-created time estimates into some kind of real estimate behind the scenes, but that’s what points are actually already doing for you, but in a very reliable way that only makes claims that the data gained from tracking those points supports.
Furthermore, using points doesn’t cost anything when you get down to it. Yes, you have to invest into story refinement and planning poker, etc. But most of that work is already being done somewhere. We need to estimate stories to put in a sprint, and we need to break down work to trackable chunks. If you aren’t doing it beforehand (the way Scrum suggests), then it’s just happening ad hoc during sprints, which makes them very unpredictable. It also makes it hard to transfer stories from one person to another, since it’s a lot more likely that context is living in someone’s head instead of being written down.
Story-Pointed Scrum
Scrum has gained popularity for being one of the easiest ways to actually gain predictability while still being agile, and I’ve seen it be incredibly effective time and time again. It does take a little practice of course, and requires buy-in and trust from a whole organization, from team level to leadership level. With a little investment into your process and some practice, the results can be astounding. There is no magic bullet for working in a totally new area with uncertain requirements and groundbreaking architecture. But the more uncertainty you have, the more important it is to use reliable tools to help you chart that territory, and Story-Pointed Scrum is up to the task.