I recently started using Scrum Poker with my scrum team to estimate user stories instead of the hour-based estimates. Scrum Poker is an interesting and useful way to estimate the complexity of user stories with a relative value, rather than in absolute hours. The advantage of this approach is that it allows 'empirical cntrol', one of the basic processes of Scrum. Empirical control and why points are more valuable than hour estimates is a topic for another blog. In this blog I want to share the rules that I use when doing estimation sessions.
Rule 1: Prepare
This sounds obvious, but make sure you are well prepared for the poker session. As a scum coach, prepare the backlog to be estimated wih the product owner. The backlog should contain mostly user stories, but it's ok to have a few tasks and bugs in there. Writing user stories is a topic for another post, but make sure the user stories are short and address the key elements: who, whatand why (e.g. 'As a customer (who), I want to put products in my basket (what) so that I can order multiple items at the same time (why)').
Rule 2: Location is key
The next step is to organize the meetingspace. Find a room that is large enough to hold the entire team and allows them to move around a bit. Preferably, don't seat the team around a table. If you really want to sit, place chairs in a circle. This allows members to look at each other while estimating and facilitates open dialogue and fits with style of daily standups. Take a break when necessary.
Rule 3: Create a baseline
Take a look at the backlog with the team and identify the item that requires the least (estimated) effort. This item has now became the (relative) baseline to compare other items with. Assign this user story a point value of 3, which leaves a little room should items unexpectedly turn out to be simpler. It's good practice to frequently draw the team's attention back to the baseline throughout the estimation session. This keeps their estimates grounded.
Rule 4: Estimate by priority
Estimate items in the backlog by priority. Begin with the items that have the highest business value. Work your way through the backlog with the team. This is useful especially when the backlog is very large and estimation can takes a lot of time. Do keep in mind that the product owner can use the point estimates to re-prioritize the backlog. But generally, this approach will make sure that at least the most important items are estimated.
Rule 5: Don't anchor
Anchoring is a psychological process where the estimates of individuals are biased based on irrelevant reference information. This might happen during Scrum Poker when one team member gives their estimate while other members are still estimating. Or when a scrum coach gives his or her own estimate before estimation begins. As a result, members will subconsciously use the given estimate as an anchor and estimates are thus biased. To avoid this bias, the coach should clearly instruct team members to estimate, for themselves, how many points they wish to assign to a user story or a bug. Team members should only reveal at the same time, when the scrum coach asks them to do so.
When the first round does not result in a unanimous estimate, members should debate why their estimates are different. Afterwards, they should simply re-estimate again. Again, avoid anchoring by asking everyone to estimate privately and reveal their estimates at the same time. Repeat the process until in the estimate becomes unanimous. Now, sometimes this will be very hard when estimates don't converge. In that case, it might help to ask the team which members are most knowledgeable, and whose estimates are probably most accurate. Their estimates can be assigned more weight for this round, but only when all members agree. If the scores still don't converge, it might be help to return to the user story later rather than force a converged estimate. Forcing a converged estimated is the last resort, and means that the scrum coach asks the team if they accept a the dominant estimate.
Rule 6: Don't average
Although it's very tempting to do so, don't average the estimates to 'get it over with'. Even when, after a second round, the estimates are still not unanimous. The point of scrum poker is that it stimulates debate amongst team members about the complexity of user stories and bugs. The primary purpose is to get everyone on the same page and bring more minds to the table to improve the estimation. This becomes especially apparent when members have to explain to each other why something is complex or what elelements other members have forgotten in their estimations. If members differ in their estimates, allow them to discuss these differences and explain their reasons. As a scrum coach you have to facilitate this, so ask open questions like 'please explain why your estimate is twice as high' or ask members to compare their estimates to other user stories that have already been estimated. It might help to ask questions like 'Why is user story X the same in complexity as user story Y?'. After a short round of discussion, members should re-estimate.
Rule 7: Keep things short
Scrum Poker should be fast-paced. Don't sit together for three hours trying to estimate everything in detail. This makes the session boring, lowers team motiviation and takes away valuable time that could've been spent implementing functionality rather than talking about it. Plus, it's an illusion to assume that estimates will become more accurate the longer you talk about it.
To keep things fast, keep things simple. Don't elaborate on user stories in detail. The point of Scrum Poker is to allow members to estimate on 'a bit more than their gut feeling'. How can this ever result in a good estimate? The key here is 'the more brains in the room in the principle'. When the team actively discusses the estimates this will greatly improve understanding of where exactly the complexity lies. The simple fact that more people estimate the functionality will already improve the estimate. This is a statistical reality. Some items will be over-estimated, but other's will be under-estimated. As a result, the estimates will even out on the project level.
I don't really like formal time-boxing for my estimation. As a baseline, I try not to spend more than a few minutes per items. If an item is very large, simply assign it a large estimate and break it down when you're about to get started on it.
Rule 8: Don't re-estimate later
Don't re-estimate individual items in the backlog at a later moment unless their scope changes. The point of point-based estimates is to determine the relative complexity of items. By re-estimating some stories, the relative orderning may be affected.
There you have it. Eight rules to effective scrum planning poker sessions. Planning poker is not easy, so it will take the team some time and practice to get used to it. As a coach, require the team to follow the rules and explain why they are important. Although no team will jump at the opportunity to estimate a backlog, these rules take away some of the pains.