Here is a new method to relate software estimations to a related base rate.
The Holy war
Nothing is as controversial as estimation in software engineering. In one corner are the people that plan endlessly and are stuck in analysis paralysis. In another corner are those that plan intuitively and always underestimate the amount of work.
In yet another area are those that do not want to estimate, as they have been in the other two corners. Ironically, they often fail to update the delivery schedule flexibly.
Everybody has his best estimation process method.
There is a never stopping genesis of new methods to plan engineering work. There are one-point or three-point-based methods. Story points or hours. Some use the Fibonacci number or planning poker.
If your planning sessions often felt like a voodoo gathering or a bazaar-like trade fair, welcome to the club.
Continuous improvement through retrospection
Retrospectives are nowadays often performed in engineering organizations. Root causes for missed deadlines and repeated failures in the development process are analyzed, identified, and solved with some remedy.
How is it then that still many tasks are delivered late?
Self Organization could be the goal.
The work in the software industry is often very complex. Some argue that this complexity must lead to new ways of organizing the work. A possible solution is the rise of the knowledge worker that owns, uses, and improves his productivity tools.
Many large organizations struggle with the realization of less hierarchical structures. It remains to be shown if such a transformation can be done by evolution rather than by revolution.
Many organizations would be better off improving their planning.
Feedback loops in the planning cycle
Planning often happens intuitively. Software engineering breaks down into many tasks. Many of these tasks are usually new to engineers that should perform the job. However, the task is usually not that unique in the engineering world. The standard advice is to have a very experienced developer (architect) comment and influence the estimation of a team. The joint assessment is often better.
In many organizations, there are only a few exchanges on how exactly these plans were.
Many plans still rely on the intuition of the engineers.
Control the engineer’s intuition through a base rate
In the book “Thinking fast and slow,” Kahneman recommends a procedure to reign in our intuitions. He makes the following example.
“Julie read fluently at age four. What is her GPA? For Americans familiar with the grading system, an intuitive answer is close to 3.7.“
This intuitive estimation is based on shared factors influencing reading age and GPA.
However, this estimation completely ignores base rate effects.
Kahneman proposes a correction method
- Estimate the average GPA (GPA=3.0)
- Make your intuitive judgment (GPA=3.7)
- Estimate the shared factors between information and base rate (30%)
- Correct the average by the percentage of the distance 3 + 0.7 x 0.3 = 3.21
I wonder if we can apply this approach to software estimation.
A base rate planning algorithm
This is my take on yet another planning algorithm (YAPA). There are some shared factors between tasks.
The first obstacle is the characterization of tasks in categories. Is the task difficult or easy?
My suggestion is to use planning poker to value complexity and work amount.
In the second step, value how long it will take. Everybody is welcome to add his two cents.
Then rate the familiarity of the task and the shared factors for the people performing the task. It should be evident that people perform depending on understanding.
Then use the familiarity to move from the average time of such a task to the intuitive judgment.
On completion of the task, modify the base rate of the task category.
The five YAPA planning steps:
- Establish a base rate: use planning poker to give story points. Value complexity and work amount of the task.
- Predict how long it will take.
- Rate the familiarity with the work (shared factors).
- Move the familiarity percentage of the difference to the base rate.
- Retrospectively update the base rate data
Has anybody tried such a system?
I have to admit; it seems pretty onerous to establish a base rate for different categories.
Please let me know your thoughts.