InfoQ

News

InfoQ Interview: Experiences with Planning Poker

Posted by Deborah Hartmann on Jul 29, 2007 06:21 PM

Community
Agile
Topics
Agile Techniques ,
Teamwork ,
Collaboration
Tags
XP ,
Planning ,
Scrum
In this fourteen-minute InfoQ interview,  recorded at the Javazone conference in Norway, Nils Haugen described the "Planning Poker" technique his teams have been experimenting with. It is a simple mechanism for arriving at estimates collaboratively, with additional team building benefits. It is also likely to improve team estimates over time. Nils Haugen is an agile developer and coach with Objectnet in Norway and has also worked with XP/Agile teams at ThoughtWorks. Hear his views on why this simple technique is an important tool for Agile teams, in the InfoQ interview: Nils Haugen on Planning Poker.

The term "Planning Poker" was coined by James Grenning in a white paper in 2002, but the technique has also been used other places, and is described in Mike Cohn’s books on User Stories and Agile Estimating and Planning.It doesn't use regular playing cards, but rather each developer has an identical deck of half a dozen index cards numbered with increasing numbers of story points - this could be a simple sequence (1,2,3,4,5,6) or a Fibonnaci sequence (0, 1, 2, 3, 5, 8). What's most important is not the cards themselves but way the team uses them.
The idea behind planning poker is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. (from planningpoker.com)
One notable benefit of using this technique is that it levels the playing field for both dominant and shy members, experts and novices. With this technique, each one must  be prepared to share the thinking behind each estimate - potentially injecting new ideas or identifying risks that might have been missed.

Despite our best efforts, it's not always possible for everyone to be in the room. A group of Agile trainers have provided a free, browser-based tool to help travelling team members or even distributed teams use Planning Poker, at www.planningpoker.com.
  • This article is part of a featured topic series on Collaboration

Related Sponsor

Join renowned software futurist & GoF Design Patterns author Grady Booch and Eclipse luminary and GoF author Erich Gamma, explore IBM's vision of the future of software development delivery in this webcast.

9 comments

Reply

Is poker a team sport? by Steven Devijver Posted Jul 27, 2007 1:45 AM
Re: Is poker a team sport? by Deborah Hartmann Posted Jul 27, 2007 6:06 AM
Is this confusing estimating with planning? by Jim Leonardo Posted Jul 27, 2007 11:22 AM
Re: Is this confusing estimating with planning? by Amr Elssamadisy Posted Jul 27, 2007 8:13 PM
Re: Is this confusing estimating with planning? by Barre Dijkstra Posted Jul 30, 2007 12:59 AM
Re: Is this confusing estimating with planning? by Deborah Hartmann Posted Jul 30, 2007 10:21 AM
Re: Is this confusing estimating with planning? by Manfred Lange Posted Feb 9, 2008 12:59 PM
Re: Is this confusing estimating with planning? by Michael James Posted Jul 30, 2007 3:16 PM
Planning Craps by Deborah Hartmann Posted Aug 17, 2007 9:42 PM
  1. Back to top

    Is poker a team sport?

    Jul 27, 2007 1:45 AM by Steven Devijver

    I thought this game is about bluffing and not trusting what the others are saying/doing.

    I think this planning game is not for shy people.

  2. Back to top

    Re: Is poker a team sport?

    Jul 27, 2007 6:06 AM by Deborah Hartmann

    > I think this planning game is not for shy people.

    I can see why you'd say that - similarly, you could say Agile itself is not for shy people. However, I've seen shy people happily embrace Agile... the key is to remove judgement from the process.

    So, in planning poker, if everyone says "4" and the shy person says "2" they will be invited to share what they know. Perhaps it turns out they see a different way to do it, which is great!. Without freedom to speak freely, this person may not have contributed this idea. But with planning poker, there is a way for them to do so without having to "butt in" to the conversation. There is an explicit invitation to speak in planning poler, which I think helps shy people learn to trust their team mates. Conversely, it teaches more outgoing team members to listen to this quiet person, to value their input.

    It is important that the person with the different estimate is valued for bringing different information to the team, rather than ridiculed for "not getting it". If, in fact, it turns out they didn't "get it", they will realize it naturally as the team discusses their idea, there is no blame involved. The discussion is about ideas, not individuals - this builds trust, which is essential to the function of an Agile team.

    Without trust, yes, the shy people on a team will remain silent and real teamwork is thwarted. But many Agile disciplines are specifically designed to build trust.

  3. Back to top

    Is this confusing estimating with planning?

    Jul 27, 2007 11:22 AM by Jim Leonardo

    Pet peeve:
    Estimating and Planning are different. This is estimating.
    To be hideously short about it: Estimate= How Much; Plan= How Long.

    I think its critical to know which you are doing when for the same reasons that we care about abstraction in code.

  4. Back to top

    Re: Is this confusing estimating with planning?

    Jul 27, 2007 8:13 PM by Amr Elssamadisy

    yes - but wouldn't you agree that estimation is one of the important pieces of information to plan effectively?

  5. Back to top

    Re: Is this confusing estimating with planning?

    Jul 30, 2007 12:59 AM by Barre Dijkstra

    I have used planning poker myself as well as introduced it with clients.

    I totally agree that it is about estimating (complexity) but I disagree that it is not planning.
    The way I see planning poker is that it is for estimating complexity and thus in the end iteration planning.
    When you know your teams velocity, in terms of complexity points per iteration, you can get a clear view what can be done in an iteration; thus the iteration planning.
    My personal experience is that, after a baseline on complexity and velocity, estimations get more and more accurate and the in the end the estimations are way more accurate then any kind of "expert opinion estimations".

  6. Back to top

    Re: Is this confusing estimating with planning?

    Jul 30, 2007 10:21 AM by Deborah Hartmann

    > planning poker is ... for estimating complexity and thus in the end iteration planning.

    I agree. Estimates are a key factor in iteration planning.

    Teams typically also go into iteration planning knowing a) their real-to-ideal ratio (ex: takes real two days to do one ideal day's work) and b) their availability (who's on vacation, taking training, etc.). So when the team reaches the iteration planning meeting, the only thing missing to create a plan is the estimate. That's where planning poker provides the "ideal time" estimates to complete the equation.

    In addition, there is a need for longer-term planning (done with a high degree of uncertainty, in Agile). I call this "release planning" and it's a different thing from iteration planning.

  7. Back to top

    Re: Is this confusing estimating with planning?

    Jul 30, 2007 3:16 PM by Michael James

    Jim's point is well taken. It would be more accurate to call this game (which I use and love, BTW) "estimation poker." Estimation informs planning, but someone else (in Scrum it's the Product Owner) still has to make a call on prioritization. "Estimation poker" doesn't have the nice alliterative ring that "planning poker" has though.

    --mj

  8. Back to top

    Planning Craps

    Aug 17, 2007 9:42 PM by Deborah Hartmann

    I got this really cool die at Agile2007 - flashy and electronic, does the usual "dice" thing - give you a random number. Perfect for Release Planning Craps!! :-D

  9. Back to top

    Re: Is this confusing estimating with planning?

    Feb 9, 2008 12:59 PM by Manfred Lange

    Yes I agree, planning and estimating are two different activities. Here is how we do it in our projects.

    Planning poker (we call it Agile Auction) is a tool or technique. It's outcome is a relative size for a task (can also be for a non-software project) in comparison to other known tasks.

    A release (= 3 months) consists of a set of iterations. Before we start a release we do a release planning. It is based on high-level stories and high-level estimates. We know that we need to adapt as we go but we still spend enough effort to get a full backlog to which the team can commit. And the team is cross-functional so there are more than just developers.

    At the beginning of each iteration (= 1 week) we use Agile Auction (aka Planning Poker) to confirm the estimates of the stories in the release backlog.

    By monitoring how many stories are completed in each week we can track the progress of the project. We can also determine the actual velocity of the team and we gain an indication of how much of the desired scope will actually get delivered.

    So estimating with cards is more about 'size' while the actual planning is more about the 'when'. Planning should also consider factors such as availability of specialists, change in size of stories if they are done in specific orders, business value of each story from a market or customer perspective, marketing value, and many more.

    In summary we found that Agile Auction (aka Planning Poker) substantially helps to improve the accuracy of the estimate (still not predictions, though!), collaboration and team learning.

    One question we are often asked is where to get the cards from. In the article one source is already mentioned. If you are looking for a free template to print and create the cards yourself you can also download it at no cost from www.agileutilities.com/products/AgileAuction

    Kind regards,
    Manfred.

Exclusive Content

Dan Farino About MySpace’s Architecture

Dan Farino talks about the system architecture and the challenges faced when building a very large online community. Dan explains how a .NET product scales on hundreds of servers.

The Maxine VM

Bernd Mathiske discusses Maxine VM, Java compatibility, swapping major VM components, research areas, Object handling, code examples, optimizing compiler, snippets, bytecode generation, JNI and JIT.

Joe Armstrong About Erlang

Joe Armstrong speaks on various aspects of the Erlang language, presenting its roots, how it compares with other languages and why it has become popular these days.

The Limits of Code Optimization: a new Singleton Pattern Implementation

The java double-check singleton pattern is not thread safe and can’t be fixed. In this article, Dr. Alexey Yakubovich provides an implementation of the Singleton pattern that he claims is thread-safe.

Pressure and Performance – The CTO's Dilemma

Diana and Jim talk about patterns observed in CTOs' activity. CTOs emerge as real people caring for other people in their organization, and are put under a lot of pressure and constraints.

Biztalk Services in the Cloud

Cloud computing feels like a tomorrow technology. Simon Thurman shows how developers can use Biztalk to create an Internet Service Bus which can be deployed locally or in the cloud.

Java FX Technology Preview

InfoQ takes a look at the JavaFX preview build and talks to Sun Staff Engineer Joshua Marinacci about the upcoming version 1 release expected this autumn.

Jeff Sutherland: Reaching Hyper-Productivity with Outsourced Development Teams

Jeff Sutherland, co-creator of Scrum, and Guido Schoonheim, CTO of Xebia, present an actual case of reaching hyper-productivity with a large distributed team using XP and Scrum.