How to estimate in software development
Estimation is easily the most incorrect thing you will do. You never seem to get it right, no matter what you do, it's either too high or too low. Then you might randomly guess bang on, but it's more a fluke than anything else. Estimation is hard because development is such an unknown process. Anything and everything will rear it's ugly head, causing you to spend much more time than you initially thought.
Why do we do estimates?
Estimates are an agile-based practice predominantly. The idea is that you have a small period of time, typically two weeks. You must bring in enough work that you can complete it all, but not too much that it's overwhelming, resulting in tickets piling up each week. This is where estimates come in, they are a guide on how long a piece of work will take, so that you can plan out the two-week period with enough work for everyone. This is important because it allows you to spread out the workload between the developers, not overloading one and under loading another. In a world where you never estimated, you would simply pick up a ticket, and it takes as long as it takes. The problem is that if one developer picked up a massive ticket, it might take weeks to complete. This then rolls over into multiple sprints, and this one developer is in a world of sadness. The agile approach is to identify when these big tickets appear, breaking them into smaller, more manageable pieces. This becomes easy when you look at a ticket and someone says it will take a week. This is ideally broken up into a smaller chunk.
How do you estimate?
This isn’t an exact science, and you should know you get it wrong majority of the time, it's the nature of the beast. You can do a few things to get it as close as possible.
First, you should have as much of an understanding of the codebase as possible. This is often the hardest thing when you first join a team, you don’t know what you don't know. This aspect usually just takes more time in the codebase to get used to. You can shortcut this a little by reaching out to people in the team that do understand the codebase much better than yourself. Give an estimate and then ask “Is this reasonable? Or am I missing something?”. This gives them the opportunity to highlight potential pitfalls that you, as a new developer to the team, don’t see.
Second, understand the complex parts of the codebase. This one might just take time, but it’s also another area where you can ask another member of the team. “What are the most complex or awful parts of the codebase?”. Every codebase has them, an area that is unmaintained, or created years ago, with layers added on top. These are the areas that take a ticket from 2 hours to 20 hours in the blink of an eye. As a new member, you won’t know these exist, until you hit them. This is where you rely on the team for guidance. I personally like to invoke a communal estimation process, rather than a single person, just because they might pick it up, doesn’t mean they will. It’s much better to get a consensus on how long a ticket will take from a group and average that out.
Third, making sure the ticket has all the requirements listed. It’s pretty hard to estimate a ticket if all it says is “add button”. You need the details on what you must add, what functionality it has and where. Furthermore, you must know the acceptance criteria. What functionality must be working for this ticket to be accepted as complete. This is vital, you can’t estimate a ticket without it. Making sure a ticket contains all these points goes a long way, but you must understand them as well. Make sure you and the team understands what you are estimating on, you have to build it after all.
Fourth, practice. Overtime, you get better at estimating. Not only on a per-project basis, but as a whole. The more you estimate, the more you get it right or wrong, which allows you to adjust your estimate the next time. Remembering the pitfalls you missed initially, you account for them the second time. You also understand the benefits of putting in a buffer to every ticket. Inevitably, more tickets get dragged in, or some bug is critical and you lose time. However, the sprint doesn’t reflect that time, visibly it just looks like you took too long on tickets. Putting in buffers goes a long way in preventing this and for time sinks.
Visibility
It’s vital you keep your team informed about the progress of your tickets. Especially when the estimate you gave is vastly under what it has taken you so far. Don’t sit, stressing out, as to why it’s taking so long. Communicate to other developers, ask for help. Make sure you keep your manager, or team lead, in the know. They will be much more impressed that you kept them up to speed than by hiding it in the dark.
Estimating is difficult, you get it wrong much more than you get it right. If you keep in mind these four concepts, your ability to estimate will dramatically improve.