Agile Development: Pointing is Pointless
Sprint Planning always made me laugh. As is customary, our team of developers would “size” all the stories and tasks we wanted to get done (we never sized bugs. I have no idea how they managed to become immune to this process.). By “size”, I am talking about pointing. We assign points to a story to understand how “big” it is. And by “big”, we mean complex. Wow this is getting confusing. We are just trying to figure out how long it’s going to take to create the thing we need. Why? Because the business is always desperate for predictably, even if that predictably is ironically unreliable.
If I had the stats, I would bet that our sizing was off 50% of the time. A small story would actually take a long time, while a big one was done in a day. It always perplexed me. Something with that kinda of accuracy is essentially pointless. I mean a broken clock is right twice a day.
If you looked at our velocity (how many points we completed in a sprint), it was always all over the place. Some time it would be 20, other times it would be 40. According to the agile gods, this number is supposed to stabilize over time. And that would make sense if teams operated in a vacuum. But team members come and go, projects change, bugs pop up out of nowhere, not all engineers have the same skills, etc. Every sprint is different, making them difficult to compare.
After these experiences, I’m almost convinced that rolling a fibonacci die is probably the best way to point things. Its random, but at least it’s fun!
In all seriousness, why are PMs and teams putting themselves through these pointing exercises when the output is useless. Pointing takes time, and quite frankly, it’s awkward for the team. The PM is sitting there saying, “Are we ready to point, are we ready to point? Bueller? Bueller?”. And the Developers are all staring at one another, because they think pointing is pointless too and are likely to just throw up a 3.
So, instead of pointing, I think the solution is actually to make everything a 3. Every ticket, task, story, whatever should be broken down into a size that a developer (or two, if your team pairs) could complete it about a day (or two). To me this makes a lot of sense.
First off, if you have tickets that are bigger than a 3, the first thing that jumps into my head is, “Why?”. Is there a lot of uncertainty around the task, or is it actually just a lot of work? If it’s the latter, then breaking it down more shouldn’t be hard, and will make the task feel less daunting. If it’s the former, then that ticket probably isn’t ready to be brought to the team.
My team starting using this approach and it felt like a weight had been lifted off our shoulders. Our sprint planning meetings because much shorter and much less painful. The process also forced us to better define our tickets and really make sure we understood what we were doing before working on it.
In terms of predictability for the business, well I just don’t think it’s possible to predict when a project will be done. According to Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
This stuff just always takes longer than you think.
The best approach I’ve seen is to draw and line in the sand, and say, “on this date, we will launch!” Then, when you get to that date, you reassess.
