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:
- 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.
- 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
This is why software companies struggle with estimating approach. They invent various tools to enhance the estimation process and improve their procedures again and again. Sometimes they get better in what they do. But there is no universal solution to the problem because there is always some amount of uncertainty about what the customer wants to see.
The agile software estimation approach recommends to accept the fact that project requirements are not stable. This is an obvious fact, but not all people agree about the way it can be applied to life. I was told that some vendors even refused to provide estimates saying that it was not possible to estimate jobs beforehand, and that clients never really knew exactly what they wanted, etc.
In the eyes of many clients this is not a great answer. They may understand that it is not possible to see the future, but they still have to understand their roadmap.
It would be interesting to answer two questions. The first one is: what a professional agile software company should do to give customers what they need? And the second one: if projects are so hard to estimate, then what is a smart, funded, savvy client supposed to do?
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.