My team and I recently tried a modified hybrid method to estimate project costs. It’s something I’d like you to see today.
This method is a combination of the Delphi method of estimation I have previously used and an agile method of estimating. For more information on why I tried something new, check out Travis’ post Cost Estimation.
My team uses poker to plan their project estimates. Planning poker is a great way to get everyone on the same page. This is a great idea. However, I love to experiment with new things to find the best. Experimentation on a regular basis is the only way to discover what works best for you.
My primary goal for this experiment was to find a method that avoids anchoring as much possible.
Let’s take a look at it.
Step One: Deliverables Defined
You must ensure that your work breakdown structure is clearly defined. You’ve probably read my book and know that I value the work breakdown structure, no matter what type of project you’re working on.
Without a clear definition of your scope, everything else will be useless. Garbage in, garbage out.
Step Two: Relative Sizing Delphi
This was the first round I used to guide my teams. It was based on the relative sizing method many agile teams use when estimating their projects.
My team was able to choose from a variety of sizes, including XXS-XXL.
You need to ensure that your teams are comfortable using any type of relative sizing model. These are relative. That means one person’s L may be different from another’s. It’s okay to explain this to your teams.
This first round’s primary purpose is to ensure that there is a good discussion and that all relevant questions are asked about what we should be doing. It’s a refinement of our work breakdown process.
Step 3: Evaluate the relative results
Once you have determined the relative sizes, you can now put them all in a spreadsheet so you can compare them. You will also have a list to help you find the answers to Step 2.
Some cases will show a lot more agreement and consistency in relative estimates than others. In other cases, there will be large variances. Relative sizing is not the same as relative sizing. This is because no calibration of estimates has been done. That’s fine. It’s when there are people who think a feature is an XS and others that think it’s an XL, XL or XXL that we need to revisit the discussion. Similar to how we plan poker, I facilitate discussion by asking questions if there is a high level of variance.
Step Four: Absolute Estimates
This step consists of two important things.
We will first discuss the relative sizing results, without mentioning who estimated what. We are trying to eliminate anchoring. This session is designed to improve our understanding of the scope and answer any questions that we have from the previous session.
Second, we do another delphi round. This time, we use hours. I prefer to use effort estimates and base them on an ever increasing scale to reflect the uncertainty that larger estimates can bring. If there are two estimates, tell your team to always round up. My hours are 5,8,13.20.40.80. Anything that exceeds 80 hours can be broken down more discreetly and you can then iterate that estimate.
Step Five: Analysis, Final Results
Finally, I compared all the effort estimates again.
