Anyone who has learned to scuba dive or climb mountains will be aware that dangerous activities should not be attempted alone. I am sure that experienced Project Managers will agree that certain aspects of their work constitute dangerous activities, but they might not have thought to alleviate the danger by seeking help from the project team and not attempting certain tasks on their own.

The best example of this is estimating. At worst, estimates can be guesses. Deciding unilaterally how long each schedule activity will take places a tremendous burden on the Project Manager and is often attempted by newly promoted managers who are familiar with the work, but might not make allowances for less-skilled people doing it. This explains why some of these estimates are absurdly optimistic.

On this page:

• The Delphi Approach: Enhancing Estimation Accuracy
• Planning Poker: Efficient Estimation Technique in Agile
• Using Story Points for Estimation in Agile and Non-Agile Environments

The Delphi Approach: Enhancing Estimation Accuracy

Although it is no longer mentioned in the Project Management Institute’s Guide to the Project Management Body of Knowledge (PMBOK^® Guide), a very useful estimation technique is the Delphi approach. Here you consult a variety of experts and get them to provide estimates for the schedule activities. These estimates are provided in confidence – a secret ballot as it were. The Project Manager then reviews the different estimates and, if they are all in agreement, those values are recorded in the schedule. However, if even one of the estimators disagrees with the others, that person needs to be questioned about the rationale behind the estimate. This is then sent to the others and they are invited to revise their estimates. If they choose not to, they need to explain why and this is reported to the person with the out-of-line estimate. This can be very time-consuming for all concerned and leads to pressure being put on the estimators to conform.

This technique has been adopted by the Agile community, specifically by a practitioner named Mike Cohn. He has exploited a feature of human nature and combined this with the Delphi process to make for very quick and efficient estimating sessions. Just like any Project Manager, an Agile manager will be expected to indicate how long the project will take. However, the Agile manager has to be responsive to change which means that the current requirements list for the project may not be the one implemented. This uncertainty means that a detailed estimating job could be a total waste of time. Mike Cohn’s work has provided a quick, efficient and surprisingly accurate way to gain a feel for the size of a project.

Planning Poker: Efficient Estimation Technique in Agile

The process he describes is called Planning Poker and the human trait it exploits is the fact that human beings are extremely good at comparative sizing. We can see two people walking down the street and know immediately which is taller. However, if asked to guess the actual height of either of the pedestrians, our guesses tend to be pretty wild.

With Planning Poker, the project team gathers together and each feature is discussed. Then everyone in the team is asked to provide an estimate. Instead of the usual time units – hours or days – Planning Poker uses a unit called the “Story Point”. To indicate how many story points you feel a requirement will take to implement, each member of the project team places a card from a special deck face down on the table. Each card contains a number and these numbers are chosen from a modified Fibonacci series. So they go: 1, 2, 3, 5, 8, 13, 20, 40 and 100. The big numbers – 20, 40 and 100 – are there for large requirements that need to be broken down into more detail at a later stage – rolling wave planning as it were.

Estimating the first requirement is difficult, especially if the project team has not done anything like this before. By placing the cards face down, we obtain a secret ballot. There is a danger for project team members to defer to a known guru and, if the cards were visible, people will wait until the guru votes and then follow suit. As with the traditional Delphi process any differences between the cards when they are turned over need to be discussed. However, this discussion takes place in public and is much quicker, as the Project Manager does not need to relay messages between the estimators.

The Planning Poker process gets much easier for the second and subsequent requirements. Now people can compare them with what went before and opt for lower or higher Story Point quantities depending on their relative sizes. Eventually, the project team will develop a feel for what a Story Point unit relates to and the estimating process speeds up.

Using Story Points for Estimation in Agile and Non-Agile Environments

If you are a non-Agile project manager, you can use this technique and supplement it by taking some of the requirements and estimating them by breaking them into their schedule activities and estimating each activity in terms of hours or days. In this way, the Story Point unit can be associated with a time unit and the remaining requirements can be converted into a time estimate by simply multiplying the total number of Story Points by the conversion factor.

This technique offers two advantages: (1) a reasonably good estimate is developed quickly and (2) it provides an effective team building exercise.

At Velopi, our PMP^® exam preparation courses cover Project Schedule Management and various estimation techniques. They also cover the other nine knowledge areas needed to obtain the PMP^® accreditation. Our Introduction to Agile and Lean course covers Planning Poker. For more details of these courses, please visit our training page, or contact us directly.