When helping people learn Planning Poker I always ask what will happen if one person plays/says their estimate before anyone else. Many people usually spot the problem and they call it “influence.” And they’re right. Sometimes a wise person says, “but I won’t be influenced”. The science of “anchoring” is well known but until recently I couldn’t think of a personal example that illustrates the problem. Happily a recent trip to San Francisco solved that problem.
I was shopping for a new pair of pants. My expected price was $75 for a decent pair of khakis. My first stop was Hugo Boss which sold very casual khakis for $150. I thought, “No way! Far too much money.” In the next few stores I saw several more pairs of pants at $100-120. But fifteen minutes after I first saw the $150 pants, I bought a pair for $100 in Bloomingdales (10% discount because I’m a Canadian). I was happy to get such a bargain. After an insanely long walk back to my hotel I realized what had just happened. Seeing the $150 pants reset my price point and now I thought that was the high end and that $100 was “reasonable”. Luckily I didn’t buy two pairs, which was my original intent.
Anchoring is subtle and it can be pernicious. One comment that really stuck with me in this area came from Dan Airely– even with everything he knows about these kinds of biases and errors he still makes these mistakes.
That is why Planning Poker estimates are done blind, no pre-conversations about the estimate.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Hi Mark
In the first ever planing poker game, the ‘experts’ kept rehashing their numbers. The non-experts nodded, just like you would expect. The problem I was solving with planning poker at the time was to get people to show quickly when they agreed, without the influence of hearing others’ opinions, so we could move on. We could save the discussion for when we did not agree. My experience is that as soon as the discussions starts, there is little hope of stopping it soon.
James,
I used to whistle at the team when these sort of discussions started up and called them for being “off-sides”. Do that enough and people learn appropriate/inappropriate behaviours. As the team gains experience and understanding of the influence Mark is talking about in his post they will eventually police themselves.
Mark: You make a great point that is often overlooked and can lead to inaccurate story point estimates. This is why I always use Mike Cohn’s free on-line “Planning Poker” tool (www.planningpoker.com).
Even if we’re all together in the same room, using the on-line tool on individual laptops eliminates the problem of “influence” since all cards are revealed on-line at the sametime. When using a physical deck of cards, I’ve seen team members change their card estimate after someone else shows their card (especially if this is a development lead, QA lead or subject matter expert (SME). On-line planning pokers hides the values until the last card is played, when all cards are revealed on-line simultaneously.
It’s also imperative that the entire team calculate these story points as a group when
using planning poker. Planning poker in isolation doesn’t work. Team members
estimate story points based on their individual understanding of a story. It’s thus possible that one team member will remember numerous testing dependencies that others didn’t understand, while others may remember that development of a related story also applies to the story being estimated, making development less work. Under this scenario, if planning poker is played with the whole team, the first round should reveal a wide disparity in story point estimates between team members. This doesn’t always happen when team members are “influenced” by each other’s estimates. Planning poker works only because of the discussions teams have around the disparity in their estimates,
then come to understand the requirement as a group. Within several rounds the entire team agrees on the story point estimate. This can’t happen in isolation and to James’ point also requires that team members do not influence each other’s estimates until after estimate disparities are revealed. Although the discussions are necessary to come to concensous on a story, the discussions must be “timeboxed” to eliminate James’s legitimate concern about long discussions that provide less and less benefit as they continue. We need to remember that some analysis has benefit, while too much analysis is a waste of time. I recommend using the 2-minute timer on the planning poker site which limits discussions between rounds to 2 minutes. You may also need to limit the number of planning poker rounds if required. This good news is that teams do learn to estimate story points more efficiently over time. John H.