A Summary of the two most important tools and techniques used in estimating software project

Estimating is attempting to look into the future and predict the time and money needed to produce a result, as Verzuh (2015) points out. Since an estimate is, well, an estimate, it can be wrong sometimes, and stakeholders normally don’t like when project estimates or budgets do not align with the final cost, as Verzuh (2015) points out.

Two important tools and techniques in estimating, as described by Verzuh (2015), are phased estimating and apportioning or top-down estimates.

Project managers like phased estimating because costs and schedules need to be produced for one phase of the project at a time, as Verzuh (2015) discusses. The phased estimating method considers that one cannot create an estimate for the complete project at the beginning of the project life cycle and breaks the project into phases. Once broken into phases, the phase estimates are completed separately. In other words, each phase becomes its separate project, as Verzuh (2015) points out. Breaking a larger project into small pieces allows the team to focus on a small phase without getting overwhelmed with the entire project and also allows the project manager to estimate and cost just a phase at a time.

Apportioning or top-down estimating starts with the entire project estimate. Once the whole or complete estimate is done, then one assigns a percent of the total estimate to each of the phases and tasks of a project, as Verzuh (2015) points out. The work breakdown structure provides the framework for top-down estimates. The work breakdown structure, as described by Verzuh (2015), gets its outputs from the project definition and risk management and identifies the tasks that become the ground for all planning that follows. The top-down estimate relies on assumptions as Verzuh (2015) describes. First, top-down estimating is based on historical data or similar past projects, which is required to make the top-down estimate accurate. The second assumption is that top-down estimates divide the project into smaller bite-size pieces and can only be accurate if the total estimate is correct. Top-down estimates are seldom as accurate as bottom-up estimates, as Verzuh (2015) points out, but they allow the project office and management to estimate the size and cost of the project.

In my work environment, we use agile scrum development. Features for the project include stories. Stories are estimated using points. Points, as described by Cobb (2015), can be estimated by each person on the team picking a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21), as a point value, which provides a level of discrimination between large and small estimates. Another method common in the agile scrum is to provide T-shirt sizes to create estimates story estimates. Both story points and T-shirt sizes are designed to give a very imprecise framework for making estimates that is appropriate to an agile environment. It helps if there is a group or team of developers to size the story. This way, one sizing each gives different numbers, and a discussion may follow as to what the level of work is and coming to an agreement on the correct Fibonacci number or t-shirt size for the story as a group. Story estimates are similar to the top-down and phased estimates described in traditional project estimating. The team breaks a feature into smaller bites (stories) and then, as a team, completes a top-down estimate (assign a point value) effort needed to complete the work in the story.

I picked the top-down and phased estimates because they resonate as a common theme across multiple project management methodologies.

References

Cobb, C. G. (2015). The project manager's guide to mastering agile : principles and practices for an adaptive approach. Retrieved from (https://onlinelibrary.wiley.com/doi/book/10.1002/9781118085950)

Verzuh, E. (2015). The Fast Forward MBA in Project Management, 5th Edition [VitalSource Bookshelf version]. Retrieved from (https://bookshelf.vitalsource.com/books/9781119086673)