Estimations: Go Big or Go Home

Estimations suck. Seriously. To do estimations properly, it requires significant analysis and a sound grip on the full project scope. It's hard. There are always unknown complexities that creep up. Estimations set expectations and impose risk when complexity is not identified.

Covering Risk

There are a couple approaches people use to balance estimates with risk. The fixed percentage model just adds a near arbitrary percent on top of a given estimate for known complexity. While this is fine, it doesn't excuse a lack of effort to try to determine what the estimates should be. Another is leveraging confidence metrics with each line item to identify risky pieces with many unknowns. This is better because it identifies the most risky pieces, but still makes estimating a dark art since it is still hard to put a number on something with many unknown requirements.

Best Practices

I have not seen any model or any approach that is perfect. However, there are some best practices here.

Each estimate may affect any feature. Be prepared for it. How can this be determined? Well, you should start by having a checklist with each high level feature. This can serve as the basis to review which features may be affected and can serve as the baseline for risk assessment. This can also serve as a useful activity for evaluating any impact on future backlog items that are already estimated. Within your backlog, the best way to manage this is assigning labels or components for these features. This will help quickly audit impact.

Estimates should be done by the team working on the project. Why? They are closest to the project and most knowledgeable about the risks. Furthermore, it helps the development team better understand where the project is going. This education can lead to better design decisions.

Estimates should be done after a full requirements gathering is complete. This effort should be done by a business analyst and should cover the full scope of the item. More than often, an innocuous item made by the client can have a rippling effect. "Change a label on this field" may require administrative changes to a data entry form, changes to the presentation layer, and changes to application logic/system messaging/inline help/documentation. You need to make the full scope visible, even for the smallest of changes.

Estimates should be client-facing. Encourage your clients to be aware of how changes may affect velocity in a project. Scope changes need to be made visible so clients do not set unreasonable expectations on when/how items should be completed.

Summary

Estimations should be handled carefully. Get smart about your backlog management, who is doing the estimations, and how they are being analyzed. This can seriously make or break project success and no one wants to be in the position of justifying a crappy estimate.