In my last post SCRUM-tastic Tuesday - Estimation guesswork, I proposed a simple approach to estimating work and managing expectations. After the post I got a few emails about the value of the Delphi Estimation method. Specifically, the writers mentioned the anonymous collection of estimates as the only real way to see how close or how far apart people see the size of a piece of work. Here is a basic summary of how it works:
- An assigning manager approaches two or more developers separately and describes a single unit of work
- Each developer estimates the work as they understand it and submits their estimates anonymously to the manager. Neither developer knows about the other and the manager does not know which estimate came from which developer
- The manager reviews the estimates. If the estimates are more than 15-20% apart the manager calls a meeting to discuss the difference between the estimates
- After the meeting, the developers re-estimate
- This process repeats until the estimates are within threshold (15-20% in this case)
This sounds complicated but it does work. This forces people to explain why they saw things so differently, often leading to the discovery of assumptions and/or risks observed by one that was not considered by the other. This approach also addresses the issue of peer pressure. We have all seen it... Put the team in a room and ask them for an estimate and often you will only hear from a few people. Unless those few people are doing all the work, you may have estimates that don't reflect what the actual assignee can commit to. This kind of communication can go a long way to ensuring your estimates reflect real concerns.
In a Scrum environment, the problem is time. The aforementioned process takes a lot of time and orchestration, which Scrum shops don't have. There is however another process that strives to capture the value of the Delphi method while prescribing a process that is fairly lean with respect to artifacts and time. Its called Planning Poker.
For me, this process gets to the heart of the matter, which is forcing full participation. The process is simple:
- Bring all the devs together. Just like Delphi, explain each unit of work and ask the developers to estimate using numbers provided on a set of cards
- Everyone shows their estimate card at the same time allowing everyone to see each others cards
- The facilitator will be able to any see big differences immediately and ask each person to explain the assumptions and/or concerns reflected in their estimate
- After a round of discussion, the team estimates again, repeating if needed
This process can go very quickly and provides all the same value as the Delphi method, although the artifacts created in this process often have a much lower fidelity. Strictly speaking, the cards are not critical... You could just as easily use yellow stickies, as long as the value choices are the same. Personally, I like using one of the many IPhone or Windows Mobile apps for this (Ex. Space Flight Orange).
While the previous example focused on dev shops this process is a great way for team managers and product owners to do rough estimation ahead of the planning sessions. This allows each party to get a sense of which pieces of work are larger or smaller and can guide selection of priorities. In this case, they are not trying to nail-down detailed estimates; instead; they are trying to define a rough approximation (often in days). This is also known as a Rough Order of Magnitude (ROM) estimate or a ball-park estimate.
Technically speaking, there is a little more to the process so feel free to read up on it. Whatever you decide to do, just remember, the most important part of getting reliable estimates from your team is getting people to communicate... chickens and pigs.