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?"
Top comments (14)
Are there any plans to release this for developers that use Mac or Linux?
I was very surprised it was for Windows...
Ideally I would like it to be available to every dev. At the moment, however, I am not sure how I am going to do that.
To be honest, when I started I didn't expect to get that far. I picked the platform I wanted to experiment with at the time and tried to prove a concept. If I was to do it today I would probably go with typescript and electron like VS Code did. Xamarin is an other option for supporting multiple platforms while using C# but I haven't looked into it yet.
Any other suggestions are welcome.
Thank you!
It is encouraging to know that other people find this useful.
I have been thinking about open sourcing the project for some time now but for different reasons.
I don't think that a c# code base will be of any use if it needs to switch to a completely different platform and use HTML/Javascript. I might as well start a new project from scratch.
In that case though, I am not sure I would be the best person to maintain a project which is based on a stack that I am not particularly familiar with.
Not at all! The more tools like GitCup available out there, the better the chances that some devs might come across and use one of them. Any credit, although unnecessary and probably undeserved, is always appreciated and welcome :)
Super interesting, but a real damn shame it is for Windows only.
The story ends abruptly with “How long do you think this will take”? Is there more, or did you hit publish by mistake, or am I missing something?
No, it wasn't by mistake. I chose to start and end the story with the same question on purpose.
After all those years and all the different methodologies I had to follow during my career I end up going through a full circle. The same question remains.
Now, I am hoping that, at some point, git and GitCup will be able to help answer that question for me but if that happens, it will be a different story.
Thank you!
Funny, I exactly worked on that sensible topic while I was deckard.ai/
They didn't get the second round of financing though... What a pity for a promising solution!
They seem to be still around. What happened? I wish we had that Jira integration 5 years ago!
The website is still up, but nothing is happening anymore, you can still try to contact them to see for yourself... :)