When Clients start to Estimate

You are having an estimation meeting with a special guest - the client. He is there to clarify features and any open questions. But during the meeting whenever the client feels that the estimation is ‘too high’ - he says: “Last time this same type of bug, had only 50% of the story points”.

What is a good response?

1. Do not invite the client to the meeting

Well, the most obvious first step is not to invite the client to the meeting. If the client is important to define the task, then have clarifying meetings with the client.

The process of estimating the tickets is an internal developer affair. Only the developers know the codebase and can make any good estimations of how long a task will take.

They are already dealing with the complexity of creating the software - usually they are not involved in how the client is being billed. It does not help that the client bullies the developers to do the work faster.

The client does not know anything about how to develop software. That is the reason he hired your team in the first place. He cannot help with the technical complexity - his opinion of how complicated the task is - is irrelevant.

If it cannot be avoided, invite the client to the Sprint Planning, then he can decide which tasks he wants to spend money on in the next two weeks.

2. You can justify the high estimate

In this case, the client compares this bug to another ‘similar’ bug.

The client is comparing it to a totally unrelated bug

If the client is comparing it with an unrelated bug. Then case closed - the two bugs are not comparable in the first place. They should have different estimations, as they are not related in any way.

The ticket the client has given is not related to the discussion and must be dismissed.

It is related to the first bug the client mention

If you encountered the same bug for the second time, then the last bugfix was not enough. This would be a warning signal that:

a) the last time the bug was not fixed (i.e. the last estimate is useless and additionally the fix needs a correction)

b) there is a deeper problem in the codebase (i.e. the estimate must be higher)

The original fix needs to be analyzed and the deeper problem with the code needs a fix. This will take more time than the simple fix that was done the first time around.

3. It does not matter what the estimate is

There is a very big misconception between “estimation” and “commitment”.

An estimate is by definition not exact. The higher the uncertainty the larger the range of the estimate is going to be. And that is a good thing. - I will get this done in 5-10days.

A commitment is exact: I am going to get this done in 5 days. It is your responsibility to honor your commitment.

With an estimate, you are in no way bound or required to finish the task in that timeframe. If I estimated it is going to take 5-10 days, and the work took 20days. Well then I suck at estimating - but it does not matter, it was just a made-up number.

However, if I committed myself - I am going to do it in 10days. And I miss that deadline I have a big problem. It was unprofessional to commit to something that I could not do.

Clarify this with your client

You should make your client aware that it does not matter what the estimate is. Reducing the estimate, will not change how much time is needed to complete the task. The time needed to complete the task is (hopefully) going to be in the estimation range. In short, his bill will be the same, no matter what the estimate is.

3. Improve your estimations

Estimation methods like Planning Poker have a step called ‘consensus’ where all devs agree upon a specific number. It appears as if the team then comes up with an ‘exact’ number.

Let’s take an example of how this can go wrong:

The devs estimated a ticket. The result? 1x3 points, 1x5 points, and 1x8 points. - At this moment nobody looked at the code or did any further analysis, they only read the ticket description. Everybody invented numbers out of thin air. The consensus for the task will be 5 points. However when reviewing the task after the implementation. It was more complicated than expected and it took the same time as a 12 points ticket.

When the client sees the result of your estimation vs actual cost he is going to be not very happy.

The consensus estimation is useless. A much better approach is to write down your estimate in a range 3-8 points.

Then you can add a second step called commitment. The developer makes a more precise estimation when he starts to implement the ticket. He knows exactly how the codebase looks like and he can do a personalized estimation of how many days it will take him to do the task. (Every developer has a different skillset, thus knows best what his abilities are and when he believes the task will be completed)

4. You are the expert

The client hired you because you are a professional developer. Something went wrong with this team. The client lost his trust in the skills and abilities of your team. Thus he tries to involve himself more.

You have to show the client - that you are the expert. The client cannot estimate tasks for you. He is overstepping his competencies and boundaries.

You must review your estimates to learn how to estimate better in the future. Additionally, you can improve your estimates by doing a code analysis before estimating. And of course, improve your processes (more tests? more manual tests?) to avoid bugs before the client sees them.

5. Do not estimate bugs

Bugs do not need to be estimated. Due to the nature of bugs, any estimation is useless. The developers did not intentionally put a bug in the software. Something unexpected happened, something the developers did not think about in the first place. They need to analyze the situation and apply a fix. Debugging can take hours or mere minutes to figure out what the exact problem is.

It is more important to set the right priorities for the bugs. So it’s clear how high the impact of a bug is. In any case, the developers should fix the bug as fast as possible.

If the ‘bugfix’ mutates into a full new feature. Then do not call it a bug - it’s a new feature or a technical improvement. That is a ticket you can estimate again.

Conclusion

You have to communicate with your client. In this scenario the client probably just had a high priority bug that needed to be fixed ASAP, and he did not have a lot of money to fix it.

You have to work together with your client. That means setting boundaries. Which meetings the client is allowed to attend and where his competencies end. This makes the communication easier on both sides.

How would you handle this scenario?