Being Comfortable With Estimation

Let’s talk about how you can prevent estimating software tasks that you feel uncomfortable about. By the end of this article I hope to give you some tips that will help you be a little bit more successful when you’re put into this situation. It’s really common in software industry and usually it is just a result of developers not knowing how to set good expectations and having a good contract with whoever was asking them to estimate the work.

So one of the main reasons why I think a lot of software developers myself included are really passionate about this subject and you’ve heard of the “no estimates movement” that’s really popular where a lot of people talk about this as it’s one of the biggest causes of burnout for software developers. If you estimate some work and your estimate turns out to be wrong many immature software companies will basically force you to work overtime and bend over backwards to meet your original estimate. They really don’t understand the meaning of the word estimate which really just means it’s not going to be accurate all the time.

If you’re out there working to deliver software for customers, inevitably you’re going to be asked to do some kind of estimation so the first thing that I would recommend that you learn to do well when you’re put into a situation where somebody asks you to estimate something and you feel uncomfortable about it is to be very clear with the other person about the unknowns. So, I often found when I was asked to estimate something I was really uncomfortable with, it was usually because I didn’t have enough detail about what was being estimated. I find many subject matter experts or business analysts or project managers even though they understand their market fairly well usually better than you as a software developer. Even though they consider themselves detail-oriented, maybe they’ve went to scrum master training or they’ve went to training on how to do business analysis but you as a software developer, you’re going to know more about the ins and the outs of the design, code and the things you need answers to.

You can get the other person to agree okay we don’t want to estimate our whole project we’re not doing waterfall but you’re still going to need to estimate something and when you get those requirements/user stories handed to you. First thing you should do is to look at it and try to find holes in it. Think of it like you’re almost a lawyer and you want to look at the requirements with intense scrutiny and try to think is there anything they haven’t considered? or are there any questions I have about this?, or when I go to develop this if I don’t get these questions answered I can’t actually commit to an estimate.

You know some companies that are earlier on in their sort of agile transformation journey they look at it like all you need to do is write a user story on your backlog and the developers will figure it out in the middle of the sprint what are all the details. This is actually a horrible idea in my opinion because it puts you as a software developer in a position where there’s no strong contract between you and what you’re on the hook for and what the business expects of you. So, you actually need to get clear about exactly what the software or the task you’re gonna build needs to do before you commit to any kind of estimate.

Lot of software developers really just want to sit at their computer and write code and kind of be left alone but the reality is if you have that kind of attitude you’re not going to really work very well with the larger team. You’re actually putting yourself into a very dangerous situation where if you don’t learn to be more detailed about that the business and other people can basically walk all over you and make your life a living hell because you’re going to do a lot of overtime as you simply didn’t take the time to understand the requirements better. So just make sure any time you’re handed any work that you need to commit to, you clearly communicate to the business this is exactly what the software is gonna do. It’s not going to do anything that isn’t in whatever we’ve used to describe it.

It’s very common that you’re going to be asked to do some work using a technology let’s say you’ve never worked with or maybe a third party component or maybe you’re working in a company where the products you work with there’s multiple teams and you need to use something that another teams building that either isn’t done or you’ve never worked with before. Rather than putting yourself on the hook to deliver something that you’re dependent on that other team for you need to actually estimate and buy estimate I mean set a time box for an amount of time that you’re gonna spend basically researching or experimenting or exploring what is it going to take for me to understand enough about what I’m interfacing with that then I can estimate it. So really, you’re just saying I’m gonna pick a fixed amount of time to try to understand what I’ve been asked to estimate.

Now some companies will really get frustrated about this they want to just push you into giving them a number so that they can commit it to management. You really want to communicate to whoever is asking you to do this estimation that the reason why you’re uncomfortable estimating at this point is because you don’t want to put them in a situation with their boss where they’re late and they look bad. So anytime I found that I have to refuse an estimate for someone it often gets down to how can I help them feel comfortable that I’m not trying to be combative I’m not trying to get out of getting the work done I’m trying to make sure they don’t get into a situation where now they’re under pressure and I am under pressure because the estimate was off. So, the way that you can help do that by clearing the floor making sure the other person understands the reason why you’re declining this estimate. Ask to do a research spike or some exploratory discovery work within a time box is because you don’t want to put them into a situation where they’re in jeopardy with their reputation with the stakeholders.

The last step that I’ll give you that you can use, that have worked really well for me as a consultant on consulting engagements is to remind them of projects or work that has been late in the past in the moment of kicking off a new project. It’s very common for them to forget completely about the project they’ve worked on in their career that’s failed and try to sort-of put rose-coloured glasses on and think well maybe this team is better than other teams I’ve worked with before in my experience.

It is more common that estimates are wrong than that they are right and it’s more common that projects go late or they’re on time but they don’t deliver to their promises than that they do and I think any one even who’s not doing software development who’s maybe not doing the work on the ground but they’re managing the effort they know this subconsciously. They’ve been through it, they remember it but you have to bring that to the forefront of their mind when they come to you to ask for estimations.

Illustration created by Thea Schukken for The Liberators & GIFs taken from GIPHY