1. Planning Poker Tool Online Auctions
2. Online Planning Poker Tool Free
3. Planning Poker Tool online, free

Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in Scrum. Planning Poker combines three estimation techniques − Wideband Delphi Technique, Analogous Estimation, and Estimation using WBS. Additional material needed for poker planning. To estimate your user-stories with the Planning Poker, you will need planning poker cards of this type: planning poker cards. You will also find applications on your mobile phones by searching: Planning Poker. Each developer will have his game (or application) card in order to participate in the votes.

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.

To get started with Planning Poker with your team, you can purchase Planning Poker cards from Mountain Goat Software. Or, play Planning Poker online for free.

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, 1, 2, 3, 5, 8, 13, 20, 40, 100 and infinity.

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.

You can learn more about Planning Poker in detail in the Mountain Goat Software store or in Mike Cohn’s book, Agile Estimating and Planning.

There is a user-story estimation method that is very popular in the Scrum universe: Planning Poker; it’s also called scrum poker. We will discover how this famous planning poker works.

When to do poker planning?

Some people estimate their user-story during the Sprint Planning but it is recommended to make a Product Backlog Refinement to refine the user-stories.

In a nutshell, the Product Backlog Refinement (Grooming) is a Scrum ceremony that we usually do once a week to refine user-stories and estimate them. The Sprint Planning will be better because the Product Owner will already know exactly what he will put in the Sprint that starts.

Here is an article on the subject if you want to know more about the Product Backlog Refinement (Grooming): Product Backlog Refinement

Additional material needed for poker planning

To estimate your user-stories with the Planning Poker, you will need planning poker cards of this type:

You will also find applications on your mobile phones by searching: Planning Poker.

Each developer will have his game (or application) card in order to participate in the votes.

We start the planning poker session

The Product Owner will present a user-story that he has completely finished (according to the definition of ready) to the developers so that they can estimate it. It’s ideal to also present the content of it by projecting the software used.

After the concrete explanation, the developers will be able to ask questions if the user-story is not clear enough; the Product Owner will answer questions and write the answers to complete the user-story.

Incomplete

If the user-story is incomplete and doesn’t allow the developers to estimate it, the Product Owner will have to keep his user-story, complete it and come back with it at the next session.

Do not estimate a user story that is incomplete or if the Product Owner can’t answer at all questions. It’s better to delay the delivery of a feature than to disrupt the entire production chain.

Complete

The developers will vote with their cards as soon as they have no more questions about the user-story.

To vote, each developer will choose a story point of the user-story. The developers will have to ask the question: “What is the story point in my opinion to achieve this user-story?”.

Concept of story point in planning poker

The story point of a user story (or a technical task) will include different notions that developers will have to take into account to estimate it:

• the effort to do to develop the request
• the difficulty (complexity) that may be the request
• the risks that we imagine to meet during the development of the US
• any unknowns existing at the time of the estimation
• potential dependencies with external elements

We must accept that the story point is an “abstract” notion that can not be compared to a number of man days. However, we could do predictability in the future.

Yes, the story point takes a notion of time contrary at the ideas that we can read sometimes. But its estimation isn’t based on it and this notion of time isn’t materialized by 1 story point = 1 day.

Utiliser la suite de Fibonacci en planning poker

To rating the story point, we will use the suite of Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21 … In general, most teams that make Sprint of two weeks use sequence 1, 2, 3, 5, 8 and 13; these teams estimate that 21 would be the rating to say that the user-story is too big and that the Product Owner have to split it.

This suite was used because higher rates suggest a higher uncertainty. When a request is very complex, needless to choose between 12 and 13, it would not make much sense; We prefer to say that it’s 13.

Voting process in planning poker

Now, the planning poker session takes place between the developers.

Each developer will choose its story point in secret, and all developers will show their rating to the entire team at the same time.

Here are the possible cases and the results of them.

Perfect osmosis during poker planning

All participants rate the same story point, so we validate this story point 1 on the user-story.

Consensus 1 during poker planning

Planning Poker Tool Online Auctions

All participants don’t rate the same thing but the gap remains correct (no more than 2 rows of difference between the smallest story point and the largest). So, we will validate the story point 5.

Consensus 2 during poker planning

planning poker consensus – poker planningAll participants don’t rate the same thing but the difference remains correct (only 1 rank of difference between the smallest story point and the largest). So we will validate the story point 5 that is the highest rating even if only 1 participant rate for this story point.

To rate again

All participants don’t rate the same thing and the gap is too big. We will ask the developers to discuss together in order to find a logical consensus. The developer who finds the request complexed can be helped if he will take the user-story; so he will lower the story point that he had estimated. Sometimes the discussion will also show that the user-story was perhaps not so well understood and that the difficulty had been underestimated.

After a good discussion, the developers will review the story point of the user-story.

Conclusion Planning Poker

The product owner will purpose the exercise of planning poker on all user-stories of his backlog that they will develop soon. He will prepare the next Sprint that he will purpose to the developers.

keywords: poker planning

Online Planning Poker Tool Free

Planning Poker Tool online, free