Breaking Free from the Traditional Approach: Agile Estimation Techniques for Better Project Management

How to break free from the traditional way of estimation in projects with the help of Agile estimation techniques and principles? Estimation is a widespread practice that businesses impose a significant emphasis on. Businesses include the estimation in their processes as a must-have part.

Typical reasons for the estimation include the following:

• To understand the cost of the implementation.
• To identify necessary capacities for future effort.
• To identify possibilities of breaking down large requirements into smaller, better manageable pieces.
• To identify potential risks early.

But is it worth it?

Even though the word ‘estimation’ is used, the outcome of the estimation is considered a precise value. Based on that, people invest massive effort into analysis to provide safe and precise numbers. That requires the involvement of critical resources as the top experts have to deliver effort (as assumed). Even worse, the effort is provided by selected roles only and not people who will be involved in the work itself once the requirement should be implemented.

Precise estimation, or even the estimation itself, is a highly possible waste!

Companies try to improve estimations with “precision correctors” or some form of relative estimation, i.e., T-Shirt sizing. However, they still search for precise, not accurate, numbers only.

The estimated value is considered a baseline to which the implementation is compared. All these pitfalls lead to the manipulation of numbers. The estimation results contain too much buffer, lowering the willingness for adaptation in case of risks or changes identified in the implementation. They support a lock of resources as estimation is often provided per skill, capacity, or person.

The effort is estimated in time (hours, days) or work units (man-days, person-months). That is either vaguely provided by only a few selected people, or we assume that people estimating the job will do the job later. This approach doesn’t include professional growth into effect or change of technologies, processes, or even tools. Estimates provided now will probably be highly shortened in the future as people will get new knowledge meanwhile.

To summarize this, more effort is invested into the estimation itself:

• the longer time for delivery,
• the less precision,
• the less willing to adapt analyzed and estimated solutions,
• the more significant cost invested into the preparation.

Agile Manifesto focuses businesses on delivering value in the form of working products, building in close collaboration with customers to react (or even initiate) to changes. With the help of leaner processes and wasteless practices.

Estimation in agile is therefore built on different premises:

• Search for accuracy, not precision. Precise estimation is worthless, time-consuming, and requires key resources. Produced values often need to change in the implementation due to changes proposed between estimation and implementation. Agile, therefore, prefers relative comparison.
• The comparison is made in relative units, i.e., T-Shirt sizes, Fibonacci[1] scale, or widely preferred modified Planning Poker®[2]
• Some problems or requirements are selected as references to which others will be compared. The references are chosen based on historical experience or best guess. Multiple types of requirements are considered in the selection of references.
• The estimation is done by a group of people, the team, or the crowd who will work on it.
• During the estimation activity, we build an alignment in understanding the requirements and implementation approach. Misalignments are identified, and estimation is repeated based on findings.
• Estimation is the best guess, nothing more.
• We estimate to decide if further development is worth it, not how much precisely it will cost.
• Do not over-invest time into estimation itself. Change is always near.

[1] 0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ….

[2] Planning Poker is a trademark of Mike Cohn, The Mountain Goats Software Company. Values are 0, ½ , 1, 2, 3, 5, 8, 13, 20, 40, 100

The first important step is establishing team agreements and principles in relative estimation.

1. Select reference requirements based on your historical records. Or select a few for every number on the scale.
2. Identify multiple candidates for different requirements types, i.e., user story, bug, support, and research.
3. Choose the scale used for the estimation. It might be T-Shirt size (hard to use for prediction), Fibonacci, or Planning Poker® scale.
4. Agree on maximum size, which will guide you to break down large requirements into smaller ones.
5. Define estimations perspectives that should be considered (complexity, dependencies, risk, effort).
6. Scales or estimation perspectives can be adapted over time.

Once these principles are agreed upon, the team can start with the estimation, i.e., Planning Poker. Planning Poker® is one of the Agile estimation techniques.

For every estimated requirement:

1. The Product Ownership role (Business owner, product owner, epic owner, architect, stakeholder) explains the estimated requirement briefly.
2. Team members separately decide on the estimation by asking themselves: “How many times is more or less complex compared to our references?” It takes 5-10 seconds for that.
3. Numbers are shown to the group simultaneously to overcome strongly opinioned personalities and provide a space for silent ones.
4. The group discusses differences in estimation to understand deeper reasons for the difference that should be worth considering in the re-estimation.
5. The group repeats the estimation couple of times (2-3 times maximum) to find one final number.
6. The discussion can be worth evidence for future implementation, but it is not necessary.