In software development, companies prefer to be ‘agile’ which in practice means they can tell you what features you might receive within 1-2 months but the end date remains unknown. What if that’s not an option?
When you go to a construction company and ask to build a house for you, you (should) require them to tell you how much time and money it will take. Some justified delays are acceptable but you will rather not put up with a situation where the construction will keep going forever!
This article won’t be about the luxury case where you just get a task and can say that it will be done when it’s done.
This is also not about – so-called – T-shirt sizing, where you will be doing some clairvoyance without digging into details.
Here I will share my experience in making an accurate estimation from a perspective of a software developer who is asked to estimate a task – a clearly defined expected result but no implementation details. He is not interested in reading thick books on estimation, he can’t go agile and say that next sprint you’ll get these few features. He is still required to give numbers and dates to which he will commit.
Note that I am usually supported by a team but I don’t know the details of their job (unless they are devs too) and therefore can’t estimate it. If your estimation needs to include e.g. testing then you need to ask a tester/QA specialist (or ChatGPT – but I wouldn’t bet my money on what it says).
Before we begin I want to share 2 stories (real) to give you something to think about.
I once had a situation like this:
Manager: Welcome to the team, Chris! We hired you because we have an application that was supposed to be delivered in November last year (it was February then) and now the ultimate deadline is in May. Now let me tell you about the project…
At this stage, you can think any estimation is pointless and you need to jump right into the code to deliver whatever’s possible.
Well, not quite.
First, notice that someone has messed up the estimation before (or maybe there was no estimation at all). Why would you think the app can be finished by May? If you tell your manager in May that the deadline will be missed again, there might be severe consequences. If you can expose to him right now that this is not doable, he might not be delighted but he’ll have a chance to mitigate the risk (e.g. get someone to help or negotiate fewer features).
Here’s another story:
Sales: Hi Chris, how’s it going with the app?
Me: Oh, ok, thanks. If everything goes fine we should have it ready in half a year. Why?
Sales: Half ‘ year? Hmm… no good. I thought it was almost ready when you showed it last week so I just sold it to a few customers and promised them they should have it next month…
So what now? Are we wrapping up our sleeves and forgetting about all our estimations just thinking we can squeeze 6 months into 1?
In my case, the project manager managed to recall all the sales and made sure they won’t sell anything before we were ready and that’s the best that can be done.
If you can’t say ‘No’ for some reason I would start by negotiating overtime. Re-estimating doesn’t make sense (unless you are forced to drop tests out – since we are not working by the rules anymore anyway). Better check if you can change priorities and/or create some shortcuts (which you also estimate), at the same time adding tasks to fix them (size them later).
To sum up, remember that if there is any timeline included, a proper estimation is a must.
I mentioned a clear task – which is the key requirement. Without it, it will be ‘it’s done when it’s done’. It requires cooperation between the developer and a client (keep in mind that a client can be internal, e.g. the company director – it’s the person that gives you the task).
When you build a house, you hand over the plans and the task is to build a house according to them.
Similarly, when a software developer is given a task, he also needs to clearly understand what to build, how it should look, what are the constraints, etc.
Missing this key point is a frequent sin on both sides. On a number of occasions, I have been given very blurry tasks, where the client gave us an idea without any details and requested an estimation. I’ve also seen adventurous developers taking on this challenge:
“I want to have a website where you can have set a theme and just change the text and it needs to integrate with our messaging system – how much is it going to take?” – asked one of the managers from a company I once worked for.
“Hmm, the website is simple but the messaging… at least a month, but shouldn’t be more than 3” – was an answer I heard from one of my colleagues. It took over a year before we released an initial version.
You need to be able to tell which details need to be defined by the client and which not. If we continue with the house example, you don’t care where they take concrete from and how they mix it. As a software developer, you won’t tell the client that you need to add another table to the database – he doesn’t care, he wants the result.
In summary, the developer and the client need to work together and make sure they have defined the end goal they both understand. It’s best to do it in writing as the memory tends to fade away. If something has been missed, they need to sit back together and add it.
Now lets set up an example:
Imagine you maintain the website of a ticket office. The company is entering a new country on the other side of the globe. The management approaches you with a task:
Translate the website
They need to prepare a sales campaign in advance but can’t start without a website, so they need to know in advance when it will be ready. You can’t rely on a hunch for this. You need to estimate!
Big tasks (projects, epics) consist of smaller subtasks. The game is to define sizable tasks. You need to be aware that there are often some that are unknown, so we need to strip them down as much as possible.
How to do it?
Sometimes a solution for a task or its portion already exists, so before you begin, search the internet for a bit. Maybe someone has already done this before? If yes then you might save a lot of time and errors!
Oh, there is a solution but you don’t like it?
One of the companies I worked for has created its own ORM. I don’t know why, probably they didn’t check if what they needed already existed and wrote it themselves. Whatever the reason was, they forgot about transactions, and a few months later they had gigantic problems with incoherent data.
If you think you can do something better than someone else before – go ahead. Just remember, sometimes there are reasons they did it the way they did.
Ask yourself this question:
“Do you know what code (or any other) changes need to be done?”
No? So you need to do some research. During my career, I found that it is often a good idea to have a separate task for investigation.
At the end of an investigation, we should either have a good description of the task at hand from a developer’s perspective or more tasks, especially if the task seems big.
There is a chance you are using some kind of ticketing system (e.g. Jira). If not – start making notes somewhere. You can even use a good old-fashioned notebook (I use both).
Write down everything you think you would need to do to finish the job, including:
In a few companies I worked for we were using ‘kanban boards’ and the policy was to put ‘user stories’ only on it, meaning only features visible from the perspective of a user of the software. These are good to demo to a client but, they are counter-intuitive for estimation – they obscure the tasks that need to be performed.
E.g. pages for adding and editing a ticket reservation might be 2 user stories but most of the code will probably be shared for both cases and you’ll only load some data or not and maybe switch some text depending on which scenario you have.
Think about building a house again: if you plan a kitchen next to a bathroom, for you they are 2 separate spaces. But there will be just 1 wall separating them and pipes will be led only once, just forked in the end. Does your builder estimate it separately? If ‘yes’ then you are getting ripped off.
So, if pure user stories on a board are also your case then I would advise having a separate board with ‘developer stories’ as a basis for your work and linking user stories to them. Theoretics say this is a ‘waste’. I’m a practitioner and for me, this is a tool for correct estimation.
The task seems straightforward. Nevertheless, it’s too high-level to be estimated (in agile terms you can probably think of it as an epic). What code changes could there be? Isn’t it just work for a translator? Well, usually the texts are tangled somewhere in code so let’s assume that there actually is some work for you.
Is the website capable of switching between languages? No? Then it’s a new task which, apart from the implementation itself, will require you to find out what options there are, present them to the client, and wait for them to pick one.
How do you store texts? Do you keep them in the same place like a resource file or a database? No? Then you need another task.
Ok, so we already found that apart from the translation itself there are 2 other things to do. Now’s the easy part. Did I say easy? Then how much time is it going to be to replace all the hundreds of places that display some hardcoded text? And remember about those that come from a database, too!
Ok, so by now we should finally have tasks we can really estimate. Now’s the time for a ‘hunch’.
If you’re the only person that will estimate then you can put numbers right away. If you are estimating in a team then you need to make a note separately so that you don’t influence their votes. Whichever your case is, make sure your number is based on your own research and experience.
You might be tempted to change your mind after hearing opinions from people that are more experienced, better with the technology, or just smarter (and you don’t want to look inferior). Or didn’t do any analysis but still say things like “This is just 1 line of code” or “I can write it in 1 evening” – if you hear these, make sure they get these tasks.
When you have a task:
The place where most estimations get blown away is the ‘unknowns’ and the time spent to uncover them (e.g. when you want to use a tool you’ve never used). You can’t estimate that.
If you were working in Agile now, you’d probably have a timebox for research at the end of which you’d create another task for development.
Remember, this is not agile here. At the end of the estimation, we are required to give a number, a date, or a range.
First of all, check if the unknown can be quickly unveiled. Maybe there are some examples of people having the same problem, maybe ChatGPT can give you a hint…
If you had no success then what seems to work for me most of the time is having 2 timeboxes right away.
The 1st one I use to investigate and try out the optimal idea (like you’d do in agile).
In the 2nd I assume that the 1st timebox didn’t provide anything sensible and I will be implementing a dumb and ugly workaround, which can be sized using one of the hints mentioned before.
There is a chance that the 1st timebox works and this timeslot will be used for implement it.
Finally, when handing over the estimation, announce in capital letters that there is a risk that this item will need further work to replace the workaround.
Comparing a present task to one from the past is often a good idea. You can see the solution that was performed and if it didn’t have any estimate then just assess it. If it was estimated then you can try to reuse it, but please be aware that:
On with our example:
Even with the finest scrutiny of the task you are likely to miss something or approach complications.
Let’s assume you’ve done some (or all) translations for our exemplary website and you proudly give it to a service assistant from the other country to test it. He tells you that while the text does get translated, the hours are totally wrong!
Of course! You’ve forgotten about the time zone change!
That’s why in the end I would suggest adding a suitable extra amount of time. It might not be enough to fix everything you missed but you should get at least be able to announce that and take any necessary precautions.
Typically, you’ll have a low buffer for a new project in a known technology or a well-maintained existing one. I would add some 10-20% to the overall time here.
On the other side, there are huge, old projects, created without thinking about any good coding practices. I would even triple or quadruple the time because, apart from being hard to analyze and work with, they also have a nasty ‘butterfly effect’ where when you change 1 thing, something else (often unrelated) breaks elsewhere.
A feedback loop is a very important factor. It’s one of the things that make up intelligence, that’s how we learn. That’s why, if possible, make notes of how long a task really took (whether it was done by you or a team member). Put it next to the estimate. When you gather several of these, adjust your multiplier.
Have a look at any extra tasks that popped up.
Finally, contrast the numbers with the total expected time and if the buffer was enough.
I hope that my experience I shared here can help you a bit when you’ll be asked to estimate a project.
And if you have made it this far then I have one last thought for you:
We all know how software development looks like, right? Certainly like this:
And definitely nothing like that:
Bear it in mind when you estimate.
Happy coding!
After carefully evaluating suppliers, we decided to try a new approach and start working with a near-shore software house. Cooperation with Hicron Software House was something different, and it turned out to be a great success that brought added value to our company.
With HICRON’s creative ideas and fresh perspective, we reached a new level of our core platform and achieved our business goals.
Many thanks for what you did so far; we are looking forward to more in future!
Hicron is a partner who has provided excellent software development services. Their talented software engineers have a strong focus on collaboration and quality. They have helped us in achieving our goals across our cloud platforms at a good pace, without compromising on the quality of our services. Our partnership is professional and solution-focused!
The IT system supporting the work of retail outlets is the foundation of our business. The ability to optimize and adapt it to the needs of all entities in the PSA Group is of strategic importance and we consider it a step into the future. This project is a huge challenge: not only for us in terms of organization, but also for our partners – including Hicron – in terms of adapting the system to the needs and business models of PSA. Cooperation with Hicron consultants, taking into account their competences in the field of programming and processes specific to the automotive sector, gave us many reasons to be satisfied.
