In any (software) development project, the goal is to make the most out of available resources and find the right balance between time and money. The project owner (client or partner) wants to have an exact idea of how much the project would cost, while developers prefer having an exact idea of all the features and how they behave in order to protect themselves.
Why? Because in the process of software development, there’s always a chance that something will go wrong.
Wait, wait… Do developers also give estimates?
Of course – it makes a lot of sense because we will be developing that feature in the first place. Those estimates depend on the type of the project, but a few recurring parameters always reappear – developers’ experience, what we have already seen and developed, or what’s new and challenging – and of course – our state of mind at that precise moment of giving the estimate.
The Approach
I would go out on a limb and say that all developers approach the estimate phase in the same way.
If the task is big, for example: “build a blog application“, we split it into multiple, smaller particles. In the above-mentioned scenario, that would be “blog CRUD”, “displaying article”, “comment feature”, “blog review before posting”, … The reason behind that is lying in the fact that a smaller feature scope will eventually allow you to predict a more accurate estimate.
Once we have those small chunks, then you try to dissect and analyze each task. Here are a few questions I always take into account:
- The context: is the project already running? how complex is it?
- Did I ever encounter this before? Or is it a common problem?
- Does an external plugin exist, and would it fit our needs?
- Does it involve any discussion with 3rd party?
- Do I expect any issue with this?
Understandably so, there are a few things that are too contextual to mention, but this is the list I go through each time, in this exact order.
Another thing to consider is the scope of a certain feature. It is completely different to estimate a simple login feature – with username/password, few password constraints and that’s it – and a complex Return system in an e-commerce application.
What seems to be the problem?
That is the main question you need to answer, even though there will always be some unknown places.
How do you estimate project complexity? How would you estimate an unexpected potential problem? What about plugins, what if the installation does not go well?
Imagine such a feature as a Facebook LIKE button. Couldn’t be more simple, right? You just take a web page, implement the (very) straightforward procedure Facebook gives, and that’s it! Simple isn’t it? Well… Think twice.
What you also have to consider is implementing the like counter, sending notifications, and to whom, what happens if thousands of people click on the like button in a short time span, how does the dislike feature work, and how does it affect the algorithm, etc.
That said, we can now go through the 2 main different ways of estimating things that we often use.
1. Fixed budget
This one is probably the most known and asked by product owners. The idea is to simply give the most detailed specification possible, ask for a price, and stick to it until the end of the project.
Pros
On one hand, it makes the whole project easier to plan. The budget is defined, if anything takes more time than expected, it will not impact the project cost. It can also be a further motivation for us, the dev team, because it means that the faster we do it, the more profitable the project actually becomes.
If the task to estimate has a restricted scope, with very well-defined specifications, and where absolutely nothing can go wrong (which is rare, but possible) – then this is the perfect scenario!
Cons
On the other hand, we saw that there are a few unknowns in the equation. What if something goes wrong? That’s why most developers are using the pessimistic approach, if we expect something to take from 3-4 hours, then we will estimate it to 4. If there may be a few problems on a specific part, then we add a few hours on top of this. We will also expect the 3rd party communication to be slow and not precise enough, so we will expect back and forth there. And in the end, we also tend to add a small % buffer on top of the total, just in case we were not pessimistic enough, so those 4 hours could quite quickly turn up into 10 hours.
There is another huge downside to this approach for long-term projects. If one task ends up taking far more time than planned, one may increase the next estimate to balance the income. Once bitten, twice shy!
Summary
In the end, both sides may find this approach as the most fitted one since everything has a strict frame, and there is room for mistakes that will be absorbed by the buffer and the pessimistic approach. But did the bill just grow by 150% without anyone batting an eye?
As we can see in that Poll, fixed estimate tends to be less accurate. This can lead to some conflicts later, or also some overestimated tasks down the road to avoid going over the given estimate.
2. Time & Materials
The goal here is to give a min-max range, the minimum being the time we would need to complete the task if everything goes fine. If no problem pops out, and if all the parties involved in the process communicate in the most efficient way. The maximum is the case where we encounter issues, or where some explanations are not clear enough. And at the end of the task, we take the exact spent time, and bill it. No matter if lower or higher than the estimate.
Cons
One of the main problems with this approach is the lack of precision. On a big project, we can quickly come up with an estimate being 650 – 800 hours. And the gap between those two is huge! (150 hours of work is roughly 1 month) This can lead to pessimistic planning in terms of time-frame, and then result in some “holes” in the planning.
Another problem with this approach is that it allows us to give an estimate on poorly specified tasks, and then when starting to work on them, a lot of problems shows up and the estimate appears to be completely wrong.
Pros
But it has huge benefits of course.
First of all, the project’s scope can change even if the development has already started. Meaning that tasks can be added, or removed.
All in all, it gives the project owner much better control over the product and its price, and it involves them even more in the development process.
Not only will it result in a bill being more accurate related to the work done, but it will also give us, the development team, a better experience, making the project less stressful, and allowing us to have a better and more productive mindset.
Before the conclusion, there is another thing to consider when using this approach is that the communication has to be crystal clear. Especially when it comes to the time spent and if we think we will reach the max estimated time. That way, the product owner can easily adjust the scope of the feature, or allow to invest more time on it.
Summary
As a conclusion, I’d say that the Time & Materials approach seems fairer for everyone, but it has to be done the proper way, and the range has to be as narrow as possible in order not to leave too many free slots in the planning. But Danilo has a solution for that and we implemented some processes, that you can discover in his blog post.
The conclusion
We can agree that both approaches have pros and cons. If you have a small scope, that won’t evolve, perhaps a fixed budget is the best way to go. But globally speaking, the T&M model seems to be slightly better than the fixed budget. And especially if you like to work in an Agile way, without a doubt, you can not work with fixed estimates!
How do YOU approach software estimates? Any preferred approaches or perhaps you even have another one? Open the comment section below and let’s Disqus this!
