Telling the Future: Does Estimating Software Development Projects Make Sense?

To estimate or not to estimate? Estimating software development projects is tricky business. Everyone has probably asked themselves this question at least once in their software development career. If you’ve been involved in any kind of project scope estimation activities recently and wasn’t sure whether it brings any added value to your company, this article may be helpful.

Read on to find out what estimation is, what are the key arguments against estimation, and when it makes sense to estimate software development projects.

Why do we estimate software projects?

A while ago, I was asked to improve the project estimation process for our sales team. After applying a few changes to the process and carrying out a couple of meetings with technical teams, one of the developers asked me this question:

Why should we even estimate projects rather than just give our clients some rough numbers?

He mentioned a few good reasons. We work in Scrum, there are too many uncertainties involved in the process, and, in the end, the product looks completely different than what we’ve planned initially…

At first glance, this question seemed trivial. But once I considered it, the matter seemed more complicated. Was there a non-trivial answer to this question? And if yes, how could I justify it?

What is software project estimation all about, anyway?

Let’s start by defining what estimation is. It seems that not everyone perceives it the same way. According to Wikipedia, an estimation (or the activity of estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose – even if the input data is incomplete, uncertain, or unstable.

This is a general definition of estimation that applies to every type of project, including software development projects.

Still, for software projects, we’d need to upgrade it by adding assumptions and risks that are known in the time of preparing estimations (both are important for different reasons, but this is a topic for another article). 

Having established this, let’s try to answer the question: why estimate?

Against estimating software development

Steve McConnell listed a number of arguments that agree with the central tenets of the so-called #NoEstimates approach.

They are as follows:

1. Individuals and companies spend too much time on estimates.
2. A lot of the estimates are inaccurate.
3. Even if the estimates are accurate, they are ignored.
4. The time spent on estimations is a waste.

Is there anyone who doesn’t agree with these points? What is the root cause of such logic? And if these points are valid, why are we still estimating software development projects?

The Agile Manifesto!

The principal answer to my questions can be found in the Agile Manifesto:

“Customer collaboration over contract negotiation.”

In other words: if a client expects to get estimates, you should provide them. No more, no less.

This brings us to the next argument behind why estimating software development projects is so problematic. Most estimates are inaccurate. This one is also true, but there’s a good reason behind it. The truth is that teams don’t have proper skills for carrying out accurate estimations.

Like everything else in our lives, we need to learn to estimate software projects. And I’m not just talking about reducing the level of uncertainty in the project domain or increasing the level of confidence in the product we develop.

The process of estimation has been studied, analyzed, and documented for years, and there’s a good reason to take advantage of this knowledge. Knowing and using the right estimation techniques is crucial for getting the right numbers and avoiding the omnipresent feeling that we’ve wasted time.

• Read this: The Best Way of Estimating Your Product Backlog Effectively and Quickly

Estimates are not commitments!

Clients are expecting to get project estimates. We know how to make estimates, and we have the right tools at our disposal.

But at the end of the day, our values are ignored or “boosted” because they don’t look very promising from the sales point of view. Again, not diving into details – we need to be aware of the world we live in and prepared for providing the estimates expected by the client.

From a sales perspective, the situation is clear. We want to sell a product or service. Is there something wrong with that? No. Unless we’re honest and moderate the price by the number of features (or bells and whistles) with clear information to the client what they get for the price.

It gets messy once the estimates are down and dirty, too vague, without pointing out the risks and assumptions and, finally, someone makes the numbers “pretty” to sell the goddamn thing!

That’s how the client gets a dream – because they believe they will be getting everything.

Mike Cohn mentions important point in his book, Agile Estimating and Planning:

• “Many organizations confuse estimates with commitments. As soon as a team expresses an estimate, they are forced to commit to it.”
• “Commitments are made to dates. Normally the date that a team is asked (or told) to commit to is one to which they would assign a less-than-100% probability. Before making such a commitment, the team needs to assess a variety of business factors and risks. It is important that they are given this opportunity, and that every estimate does not become an implicit commitment.”

Remember this, and you won’t get into trouble in your projects.

So, should I estimate or not?

Does estimating software development projects made sense? The only answer you may get from a business analyst is: it depends.

I agree that estimation is a waste of time, but only as long as:

• The client doesn’t expect to get it,
• The team doesn’t have the right estimation skills,
• The knowledge about the product is equal to zero,
• The project is too small,
• We know that at the end of the day, the estimates are “converted” by the sales team.

We could probably find more arguments in favor of the #NoEstimates approach. But in most cases, #NoEstimates is tilting at windmills nowadays. 

In a “world of the unexpected,” businesses expect to gain at least some confidence that they will succeed. Software development teams can’t achieve that without a professional approach at various levels of software development. And project estimation is one of them.

Related posts