The problem with numbers

Looking through profiles of a variety of software development companies, I noticed that they paid special attention to their estimation approaches. On their websites they tried hard to convince the customer that they were able to estimate any job accurately. They provided so many details about how they would do that, so it was obvious (to me) that they used to be in unhappy situations many times in the past.

Estimating projects which are longer than two weeks is a difficult question. There are two common reasons why:

1. Customers never properly explain what they want to get. Please, do not find this offensive. Expressing ideas clearly is impossible unless one is taught to do it. The customer simply does not know what the other person needs to know. So, in most cases he explains the idea in a few words and then says something like: "Feel free to ask if anything is not clear", assuming that extracting the information is developer’s responsibility.
2. Developers do not consider the project as a comprehensive whole. They accept the game when the job is understood as a list of user stories every one of which should be estimated separately. Then they tend to provide estimate on every user story as if they would implement it in a speedy mode without spending time on automated tests, refining the workflow and communicating with the customer about the result.

Usually, this leads to underestimating the project. The customer gets unhappy when the estimates are not met and blames the developers while they have either to explain the new timing or to accept full responsibility for wrong numbers.

Here is where Agile estimation techniques come onboard

Software companies face challenges when it comes to estimating projects, which is why they often experiment with different tools and procedures to enhance the estimation process. While some companies may improve their methods, there is no universal solution to this problem as there is always some degree of uncertainty regarding what the customer wants.

The agile approach to software estimation acknowledges that project requirements are subject to change. Although this is an obvious fact, not everyone agrees on how to apply it. In fact, some vendors have gone as far as refusing to provide estimates, citing the difficulty of estimating jobs in advance and the fact that clients often have unclear requirements.

For many clients, this answer may not be satisfactory. While they may acknowledge that predicting the future is impossible, they still require a clear understanding of their project's roadmap.

It would be beneficial to address two questions. Firstly, what steps can a competent agile software company take to deliver the desired results to their clients? Secondly, if project estimation is challenging, what options are available to an informed, well-funded client?

What is Agile project management

As a sales manager, I completely accept the fact that a customer needs an estimate. It is my job to protect interests of the customer and keep him or her happy. Certainly, we never refuse to make an estimate. More than that, we always try to make an indicative estimate.

The agile approach is not about not making estimates. Quite the opposite, it is about re-estimating everything every week. It is not a problem to make an estimate. It is much more difficult to meet the estimate. But the "agile problem" is not just about meeting the budget. The main question is how to give the customer enough freedom and keep him from changing the initial plan at the same time.

As I mentioned before, one of the main reasons why vendors do not meet their estimates is that requirements are never fixed. The customer knows that. He is happy with that. He likes to play around with requirements, he tends to forget about deadlines, but he does not want to have the budget changed.

What do we do in such situations?

First of all, while estimating an agile project, we talk to the customer. Communication is one of the agile values. When a customer requests an estimate, we not only provide him with numbers in dollars, but also tell him what he will get for this money. We show him a plan. We attach draft graphic mockups.

Also, we ask him about his limitations. If he has a fixed budget, we estimate the job taking it into consideration.

When we start working on a project, we watch how it goes and try to catch the moment when the customer goes beyond his limitations (to do that we use our custom agile project management tool. We warn him about that and let him decide what to do.

What a customer is supposed to do

Let me summarize. The problem is not that software projects are impossible to estimate. The problem is that some customers are not experienced enough to be responsible for deadlines. They need explanations. They need guidance. If they work with an agile company, they need a "lite" version of agile – something that will give them some freedom, but will allow them not to exceed.

Also, it is reasonable to mention that we never faced any problems with estimates when the customer had experience in managing developers.

The answer to the second question is: a savvy customer should talk to the software company and get an overall opinion rather than a price. If some tasks are hard to estimate, he can ask the developers why. If a task may take one or another time stretch depending on something, he can ask what that something is. Then he can make a decision about what to do with the bottleneck.

If he is smart enough to do so, he is ready to go agile.