AndYouThoughtYouCouldEstimate
From SPA Wiki
Tutorial: And you thought you could estimate?
Presented by Niels Malotaux, N R Malotaux - Consultancy, the Netherlands [email protected] http://www.malotaux.nl
In this tutorial we first did an exercise to check our own capabilities of estimating projects, although the exercise uncovers a lot more issues, typical for software projects. In the remainder of the tutorial people got a lot of clues how to improve on these issues, in order to deliver Quality on Time from now on. Being late in software projects is not just fate. It can be overcome with methods taught in this tutorial. Because most software projects are late, it was a shame that so few people attended. Apparently the majority of the SPA2008 participants were less interested in how to get projects on time.
In the exercise everybody executed the following project: Multiplying two numbers with 4 figures each, with paper and pencil. No electronic calculator. Just using one's head.
The project process was:
- People were asked to estimate the time needed to conclude this project
- People would get the numbers from the customer
- People could re-estimate, if, once they knew the numbers, the project seemed more complicated or less complicated than initially estimated.
- People were to take the start time, do the work, take the end-time and calculate the real time needed to do the work.
- Then we started the test-phase, first estimating the time needed for this phase.
- The result of this exercise normally is a 90-100% defect rate before test and a 100% requirements-defect rate, because people without exception understand the requirements from the customer incorrectly.
There were only 3 participants in this tutorial and therefore in this exercise. The results were:
- Developer 1st 2nd Real time Est'd time Total time overrun
- Estimate Estimate Implement Test Phase (sec)
- (sec) (sec) Phase(sec) (sec)
- 1 600 300 210 >200 >410 36%
- 2 40 40 165 >200 >365 812%
- 3 60 60 247 >180 >427 611%
Issues we see in this exercise, which we also typically see in software development projects:
- Every project has something new, or something we did a long time ago: multiplying on paper we didn't probably do since elementary school. So the complexity of this exercise resembles some of the complexity of software development.
- Initial Estimation, optimistic / realistic
The exercise project takes usually 5 times more than originally estimated ("How long do you think this assignment will take?")
- Interrupts
During the project, the moderator keeps talking and asking questions about the work: Interrupts during the work consume a lot of time and attention. The Interrupt time could be deducted from the time for the actual work.
- Test
When the development is ready, how do we know the result is correct? Going into the test-phase: How much time do you think the Test phase will take? People become already a bit more realistic. Some people say: "You didn't say we had to test". Well, as long as the result of the development is right, you don't have to. The test results proved however that the results were not correct, so the development didn't deliver and apparently we needed a time-consuming finding and fixing phase.
- Test strategy
Can we minimize the test time while optimizing the confidence about the result? Example: We could decide to compare our results with neighbors. If the results are the same, we could decide that the answers were right. If they are not the same, may be both answers are wrong. No we may need a lot more time for the finding and fixing phase.
- Defect-rate
The defect rate is usually in the range of 90-100%. In this case it proved to be 100% before test.
- The test-phase was not concluded in this exercise, to save time. The point was proven. The test time was estimated, although there was no proof that after the test the answers would really be better.
- Design
There are several ways to solve the problem, although most people use the obvious way and don't check whether other ways of solving the problem might be more efficient. We know of at least two alternatives for solving the problem. Only very few people come up with these alternatives.
- Requirements
Even if the result would have been proven correct in test, all developers (exercise participants) had taken the numbers given by the customer incorrectly. Just assuming that the first figure mentioned was the most significant figure. The customer had, waving his hands, clearly indicated the positions of the figures, running from least significant first. This always works in this exercise: people assume they understand the customer, while they don't.
- Assumptions
Better assume that your assumptions are wrong. Even if you think you understand your customer, check, by early feedback! Otherwise you may come up with a perfect solution for the wrong problem.
See the SPA2008 memory stick for the presentation and several booklets about techniques how to solve the issues uncovered in the exercise. Download the booklets from http://www.malotaux.nl click "Evo Booklets" next to Niels' photo.
