The first rule of estimations: Know thyself
Understand your dice bias before rolling it.
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. ― Sun Tzu, The Art of War
Estimation is not forecasting
Let me start by saying this: Your estimation is wrong. Probably.
Here is the deal: Things will take as long as they need to get done. Estimating is an effort of trying to predict how things will happen. You won’t see all the risks, you don’t know what changes will happen, and you don’t know how long something will take (or how much it will cost). You are trying to guess.
If you had a time machine, you could go to the future, see how long it’s going to take, come back, and write it down.
Whenever communicating an estimate, explain this to whoever is receiving it. Be clear. It will save you from a lot of problems.
Voice of the client X voice of the process
When someone, may it be a client, your manager, or another area of the company, ask you (or your team) for estimation, they have expectations and constraints around it.
Look at the chart above and assume the y-axis reports the productivity of each one of those projects on any productivity (size divided by time) measure. Let’s say, for instance, it is story points per sprint (a.k.a. velocity — and also why story points should never be mapped to time).
Let’s assume that taking 10 months to complete the project is a deal-breaker. You look at your productivity, and you see that in a 2-weeks sprint, you deliver between 47 and 65 story points. In a month it will be between 94 to 130. In 10 months, it would be unlikely to deliver more than 1300 points as that was the peak productivity, and it’s doubtful you would keep that up over 10 months. The project is estimated to be over 1500 in size, so you will NOT get it done in time. You know that. If the project was somewhere around 1100 points, well, that’s very doable.
Knowing yourself allows you to have these discussions and understand where you stand. You don’t have to roll the dice and fail projects miss deadlines. In this post, I’ll talk about your alternatives to make things work in your favor.
Improve process X making pressure and working overtime
I’ve seen “managers” putting pressure on their teams and asking them to work overtime many times because either they don’t understand estimations might be wrong or because they committed to something beyond the team’s capacity (or both).
Projects don’t get delayed. Your initial estimation was wrong.
IMHO, the two most important tools to manage challenging deadlines are estimation refining and process improvement.
Refining the estimation
Of course, understanding what estimation is and the need to refine it is paramount. As the project evolves, the things that happened are no longer subject to uncertainty, and we have more knowledge about what needs to be done based on what was completed.
Re-estimating the remainder of the project might bring significant value. One of the advantages of refining it is renegotiating deadlines, scope, commitments in general, resources, or augmenting the team. This is one of the things that can be done to allow projects to be completed satisfactorily without blaming delays on the people executing them.
Process improvement
I’ve used an example above where the team’s productivity was a limiting factor to the success of an upcoming project. But what if you could change the team’s performance? Well, you can. :-) Just not by asking them to “do better.”
You need to identify the activities your team executes and how they perform these activities. In other words, make the process explicit. By doing so, you will be able to analyze with them and identify bottlenecks or activities that are not yielding good results. You can try removing these activities, change how they are performed, provide training, etc. Sometimes, just by switching the sequence of activities, you might already have a better overall performance. You need to measure the results and compare them to see if you achieved the goals.
Suppose you have a control chart like the one in the beginning. In that case, I’ll tell you that improving that while improving the mean represents better performance in the colloquial sense, while improving the variance represents improving the accuracy of your estimates.
If you like this post, please share it (you can use the buttons in the end of this post). It will help me a lot and keep me motivated to write more. Also, subscribe to get notified of new posts when they come out.
If you want to know more about charts like these and the use of statistical techniques to measure your team’s performance, I have examples in 2 older posts, and I will also share two excellent books about this:
Examples:
SEM Blog | Quantitative Software Quality Management — Part II
SEM Blog | Customer Support for Software Engineers — Part II
Books:
Book Title
by Authors
Identifier
Book Title
by Authors
Identifier