TL;DR
In the previous post, we learned why you should use sticky notes for scheduling. In this post, you will find out how not to estimate precisely work duration, but how to estimate best according to your needs. The post is based on a remarkable book written by Johanna Rothman, Manage It!
You have already learned that scheduling and estimating tasks are two different activities. Let’s learn how to do the estimation.
The SWAG
You probably did not know, but so far you used the SWAG estimation technique:
Scientific wild-ass guess (SWAG) is an American English slang term meaning a rough estimate made by an expert in the field, based on experience and intuition. It is similar to the slang word guesstimate, a portmanteau of guess and estimate.[wikipedia]
Pragmatic Approaches
The most crucial part is that tasks are small enough, so team members could provide a precise estimate. Johanna offers Pragmatic approaches in work estimation:
- Historical comparison
- Delphi and Wideband Delphi
- Do Not Trust The Team
- Serial Life Cycle Trap
- Confidence Ranges
- Date Ranges
- Three Ranges
- Separate Sizing And Duration
- Planning Poker
- Spike
Historical Compare
So you have historical project data at your disposal. It is ok to use that data to estimate work for new projects. But you must be careful because work estimation is not linear! Even if two projects differ in small amounts, the estimation difference could be much more significant.
Delphi And Wideband Delphi
Delphi means that the project manager can do work estimation with team members that will do the work. In the first meeting, team members ask questions about the project requirements, context, and scope. Then they individually provide a list of tasks, their estimation, and assumptions. Then the team gathers again and analyzes task lists to parallelize tasks that could be parallelized. The project manager adds estimates, and you are done.
Wideband Delphi is used when the project manager could not get to team members that will do actual work. Here instead of team members that will do real work, project manager estimates with their representatives, usually team leaders. Expect less precise estimation compared to the Delphi technique.
Do Not Trust The Team
Team members may be very bad at estimating. They could underestimate or overestimate work for 50%. Some members add a buffer to each task, or they are good at day task estimation and terrible at week estimation. You could talk with overestimates and underestimates team members to find out the reason for that. Talk with buffer estimates team members and make an agreement that you will try the first iteration without buffer estimates.
In the Serial or Iterative life cycle, you could use the Theory of constraints, where you add a buffer to team member estimates. Agile and incremental lifecycles are more relaxed because you will get historical data from the previous increment (sprint).
Serial Life Cycle Trap
The trap is very obvious, you try to give the total project estimate at the project start. And that estimate will be way off. Even if you are in the serial lifecycle, make a milestone that would produce a working application. Doing that, you will get real estimation data that could be used for estimating the rest of the project.
Confidence Ranges
In a lack of project information for better estimates, in confidence range, you put along with the milestone a date probability percentage. Early in the project, the probability percentage is low, but as project progress, that value increases.
Date Range
With a lack of project information, you could also use date ranges: The first milestone could be done in Q3, but we can give a better estimate at the beginning of May.
Three Dates
Here you give three dates: best, likely, and Murphy. The best date is the earliest, likely is one that you have the most confidence, and Murphy is the worst date, and you anticipate Black Swan (rare) events.
Time estimates need to be accurate (how close are we to real date) and not precise (deadline hour of the day).
Task Size And Duration
The larger the task is, the duration will be more inaccurate. You need to divide task size into smaller chunks. In poker planning, the whole team is estimating the length of the task. If you have a large discrepancy, that means that your task is too large. Do not put that working day is 100% effective. 75% is what is more realistic (6 working hours.)
Spikes
Spike is when you have an enormous task, but nobody could determine how big. Then you need to spend some team effort to break this spike down into smaller pieces.
Comments are closed.