The Setup

Some days ago a small thread by Samir Talwar appeared in the wild. He shared some insights there about story points and why anything beyond 1 point (whatever it means for your team/project) really is only useful for knowing that you need to investigate more. Or as Allen Holub put it: The Highlander rule. What a great name.

Estimations

People always want to get estimations from a development team. They want that knowledge because they want to take decisions based on that information. For example, launching a TV marketing campaign. If the app/feature is not ready for that campaign, it could mean a waste of money; Or because they need to know if they will hit their quarterly targets (one thing that maybe we need to talk about in the future); Sometimes the estimation is about if they want to use the personnel and money on a project. There is always pressure from part of the companies to provide estimates. And those estimates they become deadlines. Because estimates, for a much as people say they are not linked to time, they always are.

We, as humans, can do good estimations on short terms situations, especially when those are tasks that we have done multiple times. But the bigger is the estimate, the more unlikely is that the estimate will be correct. There are too many variables. Too many unknowns.

I always compare our industry to the construction business. We have been doing buildings, bridges, and other construction projects for over 6000 … wait, no, over 10000 years (I knew about the Bulgarians buildings). And I know not of any big construction project done on time and on budget to the original estimates. Some examples: The Elizabeth Line, the Shangri-La hotel within the Shard, Wembley Stadium, the Scottish Parliament, … If something like that happens on an industry of that age, why wouldn’t it happen to something as young as Software Development.

I’ve seen some support for the idea that we are not that bad at estimates. For example, using this study. But I think those studies tend to be flawed. For example, the study linked is an estimation of “small” programmatic tasks (and even using a 50% to 200% interval range, some of the deviations are twice/half of the maximum/minimum effort) given an expected number of lines of code (Is this study from the 90s?). The setup of the study about estimations doesn’t seem to be rooted on what I see in projects.

Though you need to have an initial idea of what a project, or a feature, could take, the unknowns are just too big for estimations to be of any actual use as representation of the likeness of the project/feature happening in a period of time.

Forecasting

Thanks to a former colleague (Chris Bimson) I got into contact with the idea of Forecasting. He has an explanation written on his blog post titled (appropriately) Forecasting. Which is pretty cool, but that just seems an extension of estimation. The idea of using past data, I had used in previous projects. Though never using variance as well as Chris is describing in his post (I have used variance within the story point estimate)

But, on the project that we used it, we really did not have user stories or features. It was mostly tasks. We had done discovery at the beginning and created a series of small tasks (most of them doable within a day) that we could use to steer the project. The forecasting worked very well as a way to see what was going to happen in the future due to the small scope of each task, and the small period in which we were forecasting (up to 4 weeks in advance).

I have used the idea since in another backend project, where I was able to reliable indicate how much work I was able to do.

The tasks used followed the pattern that Samir and Allen established: you need to know well what you are doing, therefore everything was a one (my algorithm is to break tasks into things that I think should take at most one day). If I thought something could be bigger, I would break it. If I couldn’t say that I was confident on a task created to be within the time frame, I would investigate a bit more and then would get the task(s) created/amended.

The combination of small scope and investigation is what gives your more confidence on understanding the amount of work in front of you.

The Highlander Rule

Having this kind of rule allow you to, for the short future, to produce a predictable pace. As you try to go further into the future, your knowledge of what is going to happen, and what is needed, becomes more and more fuzzy, until no investigation done now will be useful (not completely true, there could be some usefulness, but the return to the time spent is bad).