Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators.

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

When We Should Engage in Planning Poker?

Most teams will hold a Planning Poker session shortly after an initial product backlog is written. This session (which may be spread over multiple days) is used to create initial estimates useful in scoping or sizing the project.

Because product backlog items (usually in the form of user stories) will continue to be added throughout the project, most teams will find it helpful to conduct subsequent agile estimating and planning sessions once per iteration. Usually this is done a few days before the end of the iteration and immediately following a daily standup, since the whole team is together at that time anyway.

Does Planning Poker Work?

Absolutely. Teams estimating with Planning Poker consistently report that they arrive at more accurate estimates than with any technique they’d used before.

One reason Planning Poker leads to better estimates is because it brings together multiple expert opinions. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else.

After completing a thorough review of the literature on software estimation, Magne Jørgensen, Ph.D., of the Simula Research Lab concluded that “the people most competent in solving the task should estimate it.”

Second, a lively dialogue ensues during poker planning, and estimators are called upon by their peers to justify their estimates. Researchers have found that this improves estimate accuracy, especially on items with a lot of uncertainty as we find on most software projects.

Further, being asked to justify estimates has also been shown to result in estimates that better compensate for missing information. This is important on an agile project because the user stories being estimated are often intentionally vague.

Additionally, studies have shown that averaging individual estimates during agile estimating and planning leads to better results as do group discussions of estimates.

Planning Poker in Scrum

Planning Poker® in Scrum brings together multiple expert opinions for the agile estimation of a project. In this type of agile planning, we include everyone from programmers, testers and database engineers to analysts, user interaction designers and more. Because these team members represent all disciplines on a software project, they’re better suited to the estimation task than anyone else.

How Does Planning Poker Work?

At the start of this agile planning exercise, each estimator is given a deck of Planning Poker cards. Each card has one of the valid estimates on it, for example: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100.

For each user story or theme to be estimated, a moderator (usually the product owner or an analyst) reads the description. There will be some discussion, where the product owner answers any questions the estimators have. But the goal of Planning Poker in Scrum is not to derive an estimate that will withstand all future scrutiny. Instead, we want a valuable estimate that can be arrived at inexpensively.

After discussion, each estimator privately selects a Planning Poker card representing his or her agile estimation. Once each estimator has made a selection, cards are simultaneously turned over and shown so that all participants can see one another’s estimate.

Estimates will likely differ significantly. And that’s OK. The highest and lowest estimators explain their perspective so that the team can know where they’re coming from. The moderator takes notes during this agile planning session that will be helpful when the story is programmed and tested.

After discussion, each estimator re-estimates by selecting a card. Often, the estimates will converge by the second round. If not, repeat the process until the team agrees on a single estimate to use for the story or these. It rarely takes more than three rounds in agile estimation to reach the goal.

Tips for Planning Poker in Scrum

Here’s some tips for common challenges in Planning Poker:

  • Keep discussions productive: Consider purchasing a two-minute sand timer, and allowing anyone in the meeting to start it at any time. When the sand runs out, the next round of Planning Poker cards is played. This helps teams learn to estimate more rapidly within agile planning.
  • Break out into smaller sessions: It is possible to play Planning Poker with a subset of the team. It’s not ideal, but a good option if there are many stories to be estimated, as can often happen at the start of a new project.
  • Choose the right time to play: Estimating teams will need to play Planning Poker at two different occasions. The first time, teams will usually estimate a large number of items before the project kicks off or during first iterations. The second time, teams need to put forth ongoing effort to estimate new stories identified during an iteration.
error: Content is protected !!