Effective Estimation — review of Uncle Bob’s presentation
Robert C. Martin in his inspiring talk about estimates and estimations according to software explains what are the estimates, gives a lot of tips and warns from typical failures. He keeps the talk in the form of informative stories. This article is a review of Uncle Bob’s talk.
The talk is available on the YouTube:
Estimations are hard
Robert Martin propose to ask yourself: “how long does it take you to tie your shoes?” You probably answer with some small number of seconds. Your estimation would be probably very accurate and precise. Could you answer the same for a person that have never tied his/her shoes? Software development process is somehow similar because it is unpredictable. We can estimate tasks that we know but there are also tasks that we don’t know.
When you receive a specification from the client or manager it is a description in most cases. You can note down tasks from the text. Consultations with client/manager would help you to explain all inconsistencies and ambiguities from the text. After that you would be pretty sure that all requirements are known for you but… they aren’t. There is always some unpredictable problem with the technology, some functionality acts and looks different than your boss thought it should do. So the point is that we aren’t a fairy or a wizard. We are not able to predict the future.
In that case we should assume that there are more tasks than we expect. We can do that by multiplying our estimates by some factor. Uncle Bob gives as numbers from 2, 3 to even 6. Integration of tasks should also be taken into account e.g. lots of bugs can appear in the moment of integration.
“There is a fundamental rule in software that everything takes 3 times longer than you think it should, even when you know this and take it into account.”
— Robert C. Martin
Characteristics of good estimation
- honesty — The goal for this is to build trust. When you build trust, you build respect. As a professional developer you have to be respected because in other case nobody will entrust you any responsive task. To be honest according to Robert C. Martin ”you need to be able to communicate bad news and continue”.
- accuracy —Set the range for the task. E.g. it will take me from week to month.
- precision —Put precise bounds for your estimate. Take into consideration your perfect day and the worst day as reference points.
The goal for the estimation is to be 100% honest, 100% accurate and a little precise. Estimate is never a date — always a range of dates.
How to do make the good estimate?
When it comes to estimating tasks you can use methods like:
- Work breakdown structure — create one task based on the description, then create smaller ones from the big one and so on. You need to decide how deep you want to go into the tasks. Robert Martin recommends to go to 2nd or 3rd level deep.
- Planning poker — ask teammates about estimates. Each person can answer with the number from Fibonacci Sequence. Fibonacci numbers allow to make a better comparison between tasks.
With work breakdown structure you can estimate in measurable units like hours, days and so on. Planning poker allows you to making estimation in points. Those points can be converted to hours based on the calculations of team’s past speed and performance.
When manager asks
According to honest characteristic. You should always say “NO” when manager asks you to do something that is not possible in the deadline that he/she proposed.
Do not say that you will “try”. When you do that you give a promise to the manager which is not honest at all. “The lesson is: never try” just like Homer Simpson said:
How to communicate estimates effectively?
Communicate your estimates in precise ranges, do not agree on specific date. Continuously say that your estimation is a range of dates. You can show Uncle Bob’s distribution of precision as a mathematical foundation of you estimate:
For example the report has to be added to the system. In the best case when everybody in the team will be highly focused and performant, it will take 1 day. In the worst scenario it can be assumed that it will take 20 days. And the nominal is 8 days. Those values are estimates that were multiplied previously by some factor, let’s say 6.
So here we have:
These numbers allow us to draw a probability density function that I drew with using Google Docs:
Y-axis shows a probability and X-axis represents the number of days that we need to work on the report. The chart can help us during the conversation with manager. Here he or she can see what is the risk of particular estimations.
Manager can choose an interval:
or the exact number of days:
according to his or her preferences based on their risk management strategy.
Summary
I hope you’ve learned how to effectively estimate software. I highly recommend you to watch the full Robert C. Martin’s talk. He’s presenting lots of stories from his life that show the reality of the work in the software development industry.
If you have any questions or comments. Please let me know. Constructive feedback is appreciated.
