In one of my blog postings just over a year ago I suggested that mature teams may not need to use Story Points. However, at the end of that post, I wrote:
[If] your team is fairly new to writing and sizing User Stories, or if your team doesn’t yet have an established velocity, I would recommend sticking with Story Points for now because the process of assigning Story Points (during a Planning Poker exercise, for example) is *very* helpful in aligning a team’s thinking, as well as building team synergy, as the team goes through the process of having the discussions that naturally arise when sizing stories.
(You can read the full post here: link)
What I’d like to do with this post is cover a few issues on how to make sure you’re getting the most out of using Planning Poker.
First, keep in mind that Planning Poker is meant to be a very simple and quick process to be used by a team for assigning Story Points to a given story. It’s not meant to provide absolute precision regarding the assignment of Story Points, and the assignment of Story Points itself is meant to be relative to the sizings given to other User Stories on your team’s backlog.
Next, because Planning Poker is an estimation technique please don’t assume that everyone on the team must be 100% in agreement with the number of Story Points being assigned to a given Story. Let me explain: typically, when a team uses Planning Poker to assign Points to a User Story, there will be a smattering of “votes.” As an example, let’s say that, after the very first vote for a given Story, there are a couple of 3's, a 5, a couple of 8’s, and a 13. The scrum master should ask why folks who voted 3 thought the size was relatively small, and then ask the person who voted 13 why he thought the size was relatively big (i.e., over 4 times the estimated size of those who voted 3). After a brief discussion, the scrum master should ask for the team to vote again. Let’s say this time there’s one 3, several 5’s, and a couple of 8’s. A good scrum master should say something like, “OK team, let’s go with a 5 for this story and move on to the next story on the backlog.” What the scrum master is looking for is “harmonic convergence.” Notice how, in the second vote, there were fewer 3’s and the 13 went away. The bulk of the votes were gravitating towards a 5, and so you can see the team is getting closer (“converging”) on a given number. Good enough! Don’t waste time by voting again, and again, and again, and again (ad infinitum and ad nauseum) until the team members all vote the same – it’s not worth it. Estimation is not meant to be precise, and spending more and more time trying to be precise with estimates is a waste of time.
And here’s the main point that I’d like to make – let’s say you’re one of the team members who voted an 8 for this story even though the number finally assigned was a 5 – should you be upset? Should you start an argument? Should you want to keep voting until everyone agrees with you and assigns the Story an 8? No, no, and no. Even though you may really think the story should have been sized at an 8, you can see the team was converging on a 5, so just let it go and press on. Planning poker is not a contact sport.
Finally, once teams get the hang of Planning Poker, most of them vote no more than twice on any given story, and they usually don’t spend more than just a couple of minutes per story. Here’s the high-level process:
Step 1. If you've not assigned Story Points to any User Stories on your backlog then, as a team, quickly pick out what you all think is the smallest story on the backlog and automatically assign it a 1. All other Stories on the backlog will be sized relative to this Story.
Step 2. Grab the next User Story from the backlog.
Step 3. Have a brief discussion about the Story regarding the anticipated effort relative to the first story (the story itself should be familiar to the team since, if the writing of the Stories was done correctly, the team participated together in the writing of the given Story).
Step 4. Vote.
Step 5. If there appears to be a fairly strong consensus on a given number, go with that number, and then go back to Step 2….
Step 6. Otherwise, if there’s a fair amount of disparity in the votes cast, then have another brief discussion focusing on asking those who voted with the lowest number, and those who voted with the highest number, to give some insights into their respective thinking.
Step 7. Vote again – you’ll likely see some harmonic convergence on a specific number after the second vote, and then just go with that number. Now go back to Step 2 (lather, rinse, repeat)….
In sum, Planning Poker is a great technique to use to quickly assign Story Points to your User Stories. Just be sure that the team doesn’t over-engineer its use.
As always, please feel free to ask questions and share your experiences. Leslie and I look forward to hearing from you!