Estimation in software projects
My experience in software development consists of working at big companies’ internal projects. It means that main part of a job is maintenance. And new projects development happens in the environment of legacy with many integrations. It happens without fully focusing on a new project, but always as part of mentioned maintenance.
Agile and its estimation are promoted based on projects developed from zero to some working state. Each iteration adds some value to the project. No maintenance attached.
I’m not trying to say that estimations are not applicable or useful in my scenario. I want to highlight this important difference. Full time work on a project is not the same as working part time on a new project and also maintaining some others. And those are not even projects, but more like processes.
I also never worked in an experienced Agile team. While often it was declared that we work agile-style, we were not. I’ve heard, that such teams exist even in the companies I’ve worked at, but never experienced that myself.
So everything I know about Agile and related practices is theoretical cause I was interested in this approach and read about it. But I never applied it exactly or even close to what it is.
And I hate dailies. That is such a time waste! Unexperienced managers use them for micromanagement of their teams. I know that because I did it myself. The only value from such meetings in the modern hybrid/remote environment is team bonding if everyone is turning their cameras on.
Back to estimations.
I’ve always thought about them as numbers. Fibonacci, prime numbers or something like that. Made by individuals. And then discussed in teams.
And this is important. Even though I’ve always known that estimations should be discussed in the team, I’ve always thought of them as individual estimations. And that doesn’t work: in a group where people are of different levels, these numbers will be different!
Now, it is hard to separate agile estimation from complexity or time estimations. Agile one is a relative number. Team chooses one task and estimates it. Next task is estimated based on that previous estimation: if task looks bigger — estimation will raise. If task looks very big and unclear — requirements should be clarified and task split into smaller ones.
That now makes much more sense. Team estimates tasks. Team works on a project, re-considers existing tasks and estimates new ones. Team converts knowledge to better estimations.
And those estimations do not depend on individual skills. Yes, more experienced developer will burn small task faster, but it is the team effort that counts, not individual. That also means estimations could be used for burn rate and project readiness assessment. Which is the ultimate goal of Agile: get rid of illusions and understand the real state of development.
Looks like Agile estimations are useful.
But still there is a question: why did it never work in my experience? It might be “not discipline enough”. Sure, but why? I tried estimating my tasks. It rarely worked, because often I stuck in some unpredictable situations. Could be external dependency where I had to wait for someone or some team. And that wasn’t clear that I’d need it at the beginning. In other cases there were some policies that forbid me doing it in a simple way.
And that brings me to a clue. The problem is not estimations. All issues are due to lack of task understanding. And lack of careful planning of the sprints. And technical debt. Every time I hit some ugly place in the code and try to leave it better than it was, it consumes time. And then likely there are no tests that would prove my change correct. And after some time a nasty bug will appear because of this clean up. And then it is the end of iteration. How many of the planned tasks were completed?
Note the technical debt could be accumulated in the new projects too. Legacy is not old code, it is bad code. One could generate legacy in a couple of months or even weeks if they type fast enough.
And one more: Agile estimations are not the same as time estimations. You can do time estimations, but that shouldn’t be a number, it should be a range. And I’m usually too optimistic even for the worst case scenario.
This text was a form of my thoughts about the topic. It is not always logical and doesn’t pretend to cover the topic. Oh, I should have probably said it at the beginning.
