What is the point of points?

A quick disclaimer - everything that follows is just one developer's experience (guess whose lol), having been in agile/scrum environments of varying degrees for the past decade. I say varying degrees because everyone seems to do it slightly differently, which is good actually. One size seldom fits all.

The first time I was part of a team that tried using points to plan some upcoming work, I didn't get it at all. It was a few years into my first dev job, and I had enough experience to grab a card and dig in, but not enough to see (or to be honest, care) how my piece might fit into some larger puzzle.

As the years have gone by, and other places I've worked have used points too, I've grown to appreciate what they can do for planning. I don't know what the agile trainers, coaches, and other "official" sources say, but here's what I think the point (sorry, not sorry) of points are.

Building in wiggle room

Someone always, eventually comes around asking uncomfortable questions about how long will this take, and when can that be picked up, yadda yadda. They have valid reasons to ask, but what do you tell them?

The 10 years ago me might've thought, "well, the stuff I'm doing has taken some time, it'll take a little more time, and after this I'll grab that other thing that'll take time too". Now I recognize (sometimes begrudgingly) that you can't plan anything further out than today if everyone is just plugging away, and no one has a clear idea of how long anything will take.

Even when we all sit down though, talk about our feelings the details of the work, and come up with some estimates, nothing ever goes according to plan. Small tasks might take slightly longer, and larger tasks will almost certainly take more longer...er. And that's the beauty of using the fibonacci sequence instead of just straight-up points.

If the team thinks a small task might take half a day for a couple people to code and test, they might toss 2 points on it.. oh, but they have to round up to 3. Then a larger card comes along with a little more complexity. That seems like a 6, but nope.. gotta round up to 8. The next thing seems like a 9 or 10? Make it 13. More complexity leads to more surprises and unknowns, so there's a bigger jump in points the higher you go.

Setting the cadence

One of the things that drove me nuts early on was that everyone said points don't equate to hours. Except there's still 40 hours in a week and 120 hours in the typical sprint, so uh yeah they do. But exactly how many hours a point equals will vary largely by team.

Eventually, the longer a team's together, and the more familiar with the project they get, and the better everything's flowing, the more meaning points will have. If three people think a task is worth 5 points and three think it's worth 8, and they hash things out and agree to go with 8, then next time they're all more likely to go with 8 again for a similar task. And however long that task takes them to actually complete (an hour, a day, or several days) is the amount of time 8 points takes them.

Side note... either smaller teams have to be together long enough for the points to take on some meaning for them, or the entire team has to be swapped around frequently enough for everyone to come to an agreement on what a point's worth. But keeping a team together for a few months, just about long enough for them to start coming to an unspoken agreement, and then unnecessarily switching them around? Might as well toss points out the window.

Anyway, one team might err on the side of caution, point things large, but always knock them all out. Their 120 hour sprint is usually 150 points of tasks. Another team points things small, but always knocks them out too. Their 120 hour sprint is only 60 points of tasks. Either way, when the next sprint comes along, each knows about how many points worth of tasks they can commit to doing. Oh, and if anyone judges one team against another solely on points, they really don't get it at all.

Predicting the end date

End date like the end of the project, not like the "end times". What do I know though, maybe you're on a project that's so awful the end times sound preferable in contrast. This too shall pass? I hope.

The third point of points though is to predict when the project might be done. Again, it only works well if the same team is together throughout the project. If one team planned the work for their project to be 1000 points total, and they're getting roughly 100 points done a sprint, then they'll be done (using 3rd grade math) in about 30 weeks. If another team planned the same work as 500 points, and tends to get 50 points done a sprint, then it's the same deal. 30 weeks.

Of course things rarely go according to plan, due to missed complexity and requirements, scope creep, shuffling people around too much, unexpected fires, etc, etc. So at the end of the day, multiply the whole thing by the square root of pi or planck's constant and you should be fine. 😂

(If you want to read more about the scrum process, as well as agile, kanban, and other things that seem to always go hand-in-hand with scrum, Atlassian has a lot of material to check out.)