If you’re doing Scrum, chances are high that you use or at least have heard of Planning Poker.  (By my estimates, I’d say that somewhere between 0 and 100% of teams use it.)  It’s a simple and effective way to do software estimation that’s easy to understand and implement.

Considering how simple it is, you’d think that all teams would do it well – but it’s amazing how often teams are bad at it.  Like really bad.  Spectacularly bad.  Frankly, lots of teams just plain stink at Planning Poker.  And if you’re bad at Planning Poker, you’re probably just as bad at estimation, too…and that’s something you’ll definitely want to get better at.

This article will give you 5 time-tested ways to fail at Planning Poker – and how to avoid them.

A Brief Introduction to Scrum Planning Poker

If you want to do Scrum well, you need to estimate your Product Backlog Items (PBIs).  One of the most common ways to estimate is using Planning Poker.  When you play Planning Poker, your team comes together and each person brings a deck cards with values based on the Fibonacci Sequence – 1, 2, 3, 5, 8, 13, 21, 40, & infinity.  These numbers are the numbers you’ll assign to a PBI for its Story Point effort value.  Someone reads the text of a PBI out loud followed by a brief discussion of the meaning of that PBI.  Then the facilitator says “everyone vote on the count of 3.  1..2..3..vote” and everyone displays a card with their personal estimate of the size/effort of the PBI.  Initially, there probably won’t be a clear group consensus on the size/effort of the PBI so the team will likely go through several cycles of discussion and voting before they reach a consensus.

What works well about this is that they’re using a phenomenon called ‘The Wisdom of Crowds.’  The Wisdom of Crowds states that when a group of people work independently to vote on an estimate of something, the average of all the estimates will be remarkably close to the actual value.  Put another way, any individual’s estimate is probably pretty terrible but the combination of all these individual estimates is much more accurate.

FAIL #1: You’re Anchoring

In order for the Wisdom of Crowds to work, everyone needs to vote independently without undue influence.  Let’s say your team is getting ready to do the first round of voting.  The Scrum Master reads off the PBI description and you’re thinking that it sounds like a big job and you intend to vote ’21’.  Now just before the Scrum Master says “ok…let’s vote”, your lead architect says “oh come on! I can’t believe we are even bothering with this!  It’s a miniscule, tiny, two-second fix!  Ok.  Whatever.  Let’s vote.”  So, initially, you were thinking ‘21’ but now you’re not so sure.  The architect thinks it’s tiny and you have 1) zero desire to contradict him and 2) zero desire to look like an idiot in front of your team – so you decide to play it safe and vote a 5.

By voting ‘5’ (instead of ’21’), your personal vote just got skewed.  It’s pretty likely that this didn’t just happen to you either – at least a couple of other people on your team had that same reaction and voted lower than they initially would have guessed.  That’s anchoring.  Anchoring happens when someone or something provides a subtle or not-so-subtle context for the estimation that causes everyone to shift their guesses.  This is a great way to decrease the effectiveness of the Wisdom of Crowds.

To get around this problem, try to keep everyone from indicating how they intend to vote.  This lets the group settle on more natural high and low estimate values thus increasing the accuracy of the overall numbers.

FAIL #2: You Don’t Discuss High and Low Votes

So your team has done the first round of voting and the vote looks like this:

If you want to be successful, what you should do is discuss the high and low values before doing another round of voting. If you discuss why Will thinks it’s so tiny and why Jean-Luc thinks it’s so large, you’ll probably learn something.  Maybe there’s an approach that is basically a shortcut that the rest of the team hasn’t thought of.  Or maybe there’s some beastly dependency on some other system that we haven’t thought of.  Whatever it is, you’ll discuss why these people think that that’s the value and everyone will get a more accurate understanding before moving to the next item.

If you want to fail, you could just ignore those differences of opinion and just move on.

FAIL #3: You Only Estimate Your Own Work

Whether you use Planning Poker or not, when you estimate PBIs in Scrum, you’re supposed to be estimating how much effort it is for the entire team to complete and deliver the PBI.  Think about the likely membership of your team – you’ve probably got a 3 or 4 developers, maybe 1 or 2 QA testers, a business analyst, and then maybe a DBA/sysadmin person.  Your team is a mix of people, roles, and skills.

Lots of teams fail at Planning Poker (or estimation in general) because each of these team members votes some kind of number that represents how long it’ll take for him/her to do only their slice of the work.  Typically, this yields estimates that are heavy on development time with moderate amounts of QA, practically no business analysis time, and then for the DBA/sysadmin whatever time it takes to deploy.  The key failure here is that they don’t vote for how long it’ll take the team but just how long it’ll take them.

Usually the reason they do this is that they don’t feel qualified to vote on the amount of effort it will take the people in the other roles.  You actually lose a lot by doing this.  Even though they might not do the work, the people in the other roles usually know a lot about the amount of effort that it will take for the other people.  Typically, this is because the team has delivered other PBIs in the past of similar complexity and everyone on the team remembers some (but not all) of the details of delivery.

If everyone votes their estimate for how much effort it will take the entire team to do all the work required to deliver the PBI, you’re taking much better advantage of the Wisdom of Crowds.  Plus, in the discussions between rounds of voting, what a QA tester says might have a big influence on a developer’s understanding of the PBI and vice versa.

FAIL #3a: We Don’t Estimate How Long It Will Take QA to Test

(see FAIL #3)

FAIL #3b: We Only Estimate the Coding Time

(see FAIL #3)

FAIL #4: No Definition of Done (DoD)

In Fail #3, I mentioned that the team is estimating what it will take for the whole team to do all the work it will take to deliver everything in that PBI.  Basically, you’re estimating everything that it’s going to take to make that PBI “done”.

You need a written Definition of Done (DoD).  Your DoD is the list of everything that it will take to complete a PBI.  And I do mean everything.  It’s a lot more than “the code is written and it’s checked in to source control.”  Typically, it’ll including development tasks as well as items related to testing, code reviews, automated builds, and deployment.

If you don’t have this written DoD, it’ll be very difficult for everyone to have a clear understanding of what it’ll take to deliver that PBI.  Basically people will be vague on what “done” means and what the steps leading to “done” are and then your Planning Poker voting will be ‘wobbly’.

As part of your Planning Poker, make sure that you’re discussing your DoD.  If you don’t, your votes almost always tend to come in way too low because you inevitably forget some of the required steps.

Summary

Planning Poker is a great way for your team to estimate.  Don’t forget to leverage what everyone knows.  Discuss differences of opinion, lean heavily on the Wisdom of Crowds, and definitely remember your complete Definition of Done.

For more thoughts on Planning Poker and Story Point Estimation, check out this blog post.

-- Need some help with estimation?  Planning Poker got you down?  Not sure what should be on your Definition of Done?  We can help.  Drop us a line at info@benday.com.