How long will it take? Git knows.

As software developers, all of our work revolves around a source control system, whether it is svn, hg or git. In every repository we use for our projects, there is a trail of our activity, commented and timestamped available for anyone to see. A couple of years ago, I started building a tool that would allow me to assign a "coffee cup size" to a work item, then use my git commits related to that work and calculate how long it took.

I call it GitCup and it is still a work in progress but its purpose is to help me generate more accurate time estimates with the least effort possible.

"Why?" you might ask.

I remember the first time the team I was working for, decided to start using scrum as a way to become more "Agile". We spent countless hours debating whether we should be using Fibonacci numbers or powers of 2 (1,2,4,8,16) for our story points. We switched back and forth a couple of times but we couldn't agree which one was better. Then we would argue over and over again whether a story was 4 or 8 points and what does that mean anyway, is it twice as difficult to do or does it take twice the time? You see, back then I was in favour of the Fibonacci range (1,2,3,5,8,13) as a scale for rating the "complexity" of each user story. I was, of course, wrong.

Fast forward a few years later, at a different company and in a different team, I found myself in a mixed Kanban/Scrum flavored variant of "Agile". At some arbitrary point the upper management decided that an "Agile" revamp was the first step to a new "digital transformation initiative". They hired a consultancy firm and our team got an "agile coach" to guide us through it.

Pointless story points

We started using planning poker cards to estimate our stories. I often felt that my 5 was someone else's 2. In the end everyone would agree with the most senior guy if only to avoid to look stupid. It was then when the term "Impostor syndrome" started to really resonate with me. As it turns out, complexity is not a very objective metric.

Our agile coach was our scrum master initially. He had a lot of practical experience and we all learned a lot from him. We would gather every morning and discuss our progress and he would be encouraging us to revise the estimate of the user story we were working on. The purpose for that was to catch early the stories that were proving to be more challenging. We would reduce the story points left if we were making progress or increase them if we had discovered some unforeseen issues and the original estimate was not valid anymore.

Time matters

That worked for a while but soon he was off to a different team and we started seeing 2 point stories being dragged on for days while 8 point stories sometimes were finished within the same day. Naturally, the morning conversations started involving questions about the "time left" for each story and people would start asking each other "Is it going to be done today?". We were using Jira already as a digital version of our board, so after a while we started including a time estimate in our stories and instead of reducing the points we were reducing the remaining time. All of the sudden points were once again used as an approximation of time. Only now we also had actual time estimates on top of that.

This was bothering me. The effort we spent debating story points or arguing over remaining hours/days during planning, the fact that we had to keep track of what we have been doing every day in order to justify the time we spent on a story and the daily update of Jiras and timesheets (yes we had those as well), felt like a huge waste. Don't get me wrong. I am not on the "no estimates" camp. I appreciate the value of a credible estimate for planning our project deliveries. I just wished we didn't have all that overhead!

What is the alternative then?

It was back then when I first thought about using our commits to track our time. Our code base was on Subversion, which makes tracking commits over branch merges more complicated, but the principle is still the same: all the history is there with comments, timestamps and actual code changes. Intuitively, I knew that there must be some way to use all that info to make a statistical prediction of future work. Much later I would find about the concept of probabilistic forecasting which can be used to make future projections with data from previous work items.

However, at the time I couldn't find any tool that was easy to use out of the box and I wasn't willing to make something from scratch myself. Our team was struggling for other reasons anyway so my investigation didn't go any further. It would take a few more years before git repositories were mainstream and I would come up with GitCup.

The itch

At some point I moved on to a new team. This time around we didn't bother to follow scrum. The team was small and distributed on many different projects. We had a bunch of stories that we would prioritize and start working from the top of that list. We would still get together in the morning and chat about our progress and of course the usual question would be:

"How long do you think this will take?"