Joining a game

Once a game is created, users have several ways to join it.

Most of the time the Planning Poker dashboard is used to get into the game. To access the Planning Poker dashboard you have to click the app logo in Jira home or Project sidebar.

Via a list of Recent Planning Poker Games on the app dashboard you can:

1. Join a game as a player by clicking "Join";
2. Join a game as a spectator by clicking "Watch".

We'll go through discovering the game roles in detail in this chapter of the Guide, but during the game process, players can change from player to spectator or vice versa as required.

The other way to become a game participant is to follow an invitation link. An invitation link can be shared with the help of a button on the dashboard or sent via email by the game's administrator, using the game configuration form.

Here is an invitation link email example:

When joining a game via an invitation link, you will always start in the role of a participant, but not a spectator.

Estimation rounds and phases explanation

The sole purpose of a Planning Poker game is to estimate all the issues that you've added to it. To achieve this purpose in the most consecutive and systematized way, the game process is divided into estimation rounds.

Each one of these rounds is dedicated exclusively to a particular issue and has a goal to decide the issues' destiny, either such issue will be postponed, deleted from the game or will get a final estimation value. Most commonly a game will consist of as many rounds as many issues were added into it in order to be estimated.

Each round consists of three consecutive phases:

• backlog phase;
• voting phase;
• discussion phase.

See below for more details about each phase.

Backlog phase

Backlog phase is the initial part of a round, where no actions are required from either players or spectators but must be "operated" by the scrum master.

In fact, during the backlog phase players and spectators are limited to observing the list of issues to be estimated, info on game participants, and on already saved estimations. As for the rest, players and spectators are waiting for a game admin to choose an issue to estimate.

The game admin has a lot of duties to perform in the backlog phase such as removing and adding issues, re-importing the whole backlog from the saved JQL query. We'll touch on each of these topics later while describing the admin's game controls. But for now, the most essential step, made by a game admin in this phase, is choosing an issue to actually be estimated by all the game participants in the next voting phase.

If the admin chooses an issue to estimate, the backlog phase ends and the round goes to its voting phase.

Voting phase

The voting phase is the bread and butter of an estimation round. Here is where the main show takes place.

Control over this phase varies based on your role — game admin, player or spectator. But the core goal of this phase is simple: the admin and the players should give their estimates to the issue of the current estimation round. And this is how it happens.

Game admin and each of the players (except spectators) receive a number of cards to their hand, depending on the deck type selected during game configuration. Typically, your cards in hand will look like this:

1. Fronts of the most cards in hand represent an estimation value;
2. Some cards fronts may have special actions on them, such as taking a break in a round or displaying an uncertainty regarding the issue estimation.

Each player and the game admin play their cards by choosing and clicking the one with the estimation closest to their own deadline, difficulty, and complexity expectations of the issue.

Cards are played face down, so the game participants won't be able to see each other's estimations until everyone has played their cards.

Once every game participant has played their card, the voting phase comes to an end.

The voting phase also ends if either:

1. Game admin has forced cards opening with their "Open cards" privilege;
2. Round timer's countdown has run to its end, in both cases if it had been started with the game admin's "Start countdown" privilege or with "Timer autostart" game's configuration option;
3. If the game participants haven't played their cards but gone AFK.

If the voting phase ends like mentioned above, all the cards played are revealed to all the game participants and spectators along with some phase's statistics and the round goes to the discussion phase.

There are also two more situations when the voting phase may end: the issue at hand may be skipped and postponed, or skipped and removed from the backlog by the game admin. If this happens, the game goes to the next estimation round or to its end.

Discussion phase

Discussion phase is the conclusive stage of the round and embodies its positive goal: to give the final estimation to the issue at hand.

This round's phase might not rely as much on the Planning Poker functionality and interface as the phases before, but it's extremely demanding in the aspect of your team communication and interaction.

The discussion phase basically acts like a round table upon which all the game participants, supervised be the scrum master, have to come to the mutual consensus regarding the estimation that should be given to the current round's issue.

Planning Poker helps to decide on the final issue's estimation by providing the following vital data to game participants:

1. As was described above, if the game had gone to the discussion phase, all the cards played had been revealed to all the game participants;
2. All game participants' estimations are displayed in vivid circle diagrams. The full chart shows estimation along with so-called "coffee cards". The simplified chart shows only estimations, excluding "coffee cards";
3. All game participants' estimations are grouped by cards according to the game's deck type.

Having all that data in front of your eyes makes it super easy for each of the players to share, explain or re-access their opinion, as well as giving the scrum master a full-scale view on the round.

If a certain estimation value of an issue has been agreed upon, the game administrator submits it. After estimation value is submitted, the game goes to the next round or to its end.

End of the game

The Planning Poker game ends if:

1. There is no more rounds to play and no further issues to be estimated;
2. The game administrator has used their "Finish Game" privilege.

When the game is ended, you'll be informed of the fact by the cheerful Planning Poker ninja. A finished game may be re-opened again.

Basic game controls

In this section, we will go through basic game controls including Planning Poker dashboard buttons, top bar, sidebar, and some others, which were not covered earlier.

Game participants of all roles and spectators share the same basic game controls most of the time.

The single exception is controls, exclusively available to a game participant with an administrator role. Such game controls will be described in the next section of this Guide.

Dashboard buttons

Planning Poker dashboard enlists all your recent games, suggesting you a number of controls over the list view and these games.

Some of these controls are already familiar thanks to the previous sections and chapters of this Guide. The  following controls are located on the Planning Poker dashboard:

1. A button that allows you to start a new game;
2. A dropdown list, that allows you to switch between whether finished games should be displayed or not. The option to hide finished games is enabled by default;
3. A text input that allows you to filter games by description, owner or state. Just start typing your desired filter, and games list will be affected immediately;
4. Buttons that allow you to join a game as a participant or as a spectator;
5. A button that allows you to clone the game, creating a new one with exactly the same configuration and backlog contents. Once clicked, a modal will appear, prompting for the name of a new game. A user, who cloned the game, becomes its prodigy's admin automatically;
6. A button that allows you to share an invitation link to a game. Once clicked a game's invitation link will be copied to your buffer;
7. A button that allows pairing Planning Poker Jira app with Planning Poker app for mobile. Once clicked, a popup will appear, containing your unique personal code to pair your mobile device app with your Planning Poker Jira app. The mobile app installation and app interface will be described in another chapter.

Top bar menu

When you hop from the Planning Poker dashboard into the game, in all rounds' phases you'll be accompanied with the top bar menu. This menu contains the following items:

1. "Dashboard" button, by clicking which you will leave the game and return to Planning Poker dashboard;
2. "Become Game Admin" button, that allows a player or a spectator to become an additional game administrator. Please keep in mind that this button will appear only if you've set up "Admin password" option in the game configuration;
3. "Sound On/Off" button, which toggle sound of estimation timer.
4. "AFK" button, that changes your status from the game participant to the spectator. Once you've become a spectator, the button will change its state to "I'm back", allowing you to return into the game, if there are participants with cards to play. If you join a game as a spectator, the button will have "I'm back" state from the beginning, allowing you to change your role to a game participant any time during any round. If you are the last participant to play their card and gone AFK, the voting phase of the round ends.

Sidebar

Along with the top bar menu, in all the round's phases, the sidebar will stick to the top right of your screen. Generally, the sidebar lists game participants and:

1. Displays game participants who have already played their cards. These names are highlighted with a grey background;
2. Displays game participants who still have to play their cards. These names are highlighted with a white background;
3. Displays an estimated points counter with a total of estimation points given to issues during the game.

Issue description controls

During the voting and the backlog phases, the first section to meet you under the game's name and description is the issue section. It contains a variety of data regarding the issue, along with the following controls to manipulate this data:

1. "Get updated issue data from Jira" button, which gets the latest info about the issue;

   Info
   title Keep your issue data up-to-date
   Once an issue is picked to be estimated by the game admin, Planning Poker automatically updates that issue's data to be displayed to the game participants and spectators. But sometimes the issue could have been updated at the same time as your Planning Poker game is on. Use this button to actualize the state.

   
   

2. "Edit issue" button, which allows editing summary, description and labels of the issue being estimated during a round. Once clicked, the button will open a modal with the issue's summary and description inputs;

   Note
   title Players can edit
   Please take a note that this button is available not only for a game's admin but also for players and spectators with appropriate access rights in a Jira project. Make sure your team uses this feature responsibly.

   
   

3. "Show comments" button. Once clicked will open a modal with a comments history on the issue being estimated during a round;
4. "Add comment" button. This opens a modal allowing to add a comment to the issue being estimated during a round;
5. "Show attachments" button. This opens a modal, displaying a list of attachments to the issue being estimated during a round;
6. "Show linked issues" button. This opens a modal, displaying a list of issues linked to the issue being estimated during a round;
7. "Show sub-tasks" button. This opens a modal, displaying a list of sub-tasks of the issue being estimated during a round;
8. "Hide this" button. This allows a collapse of the summary of the issue being estimated during a round, in case it is taking up too much screen display.

Estimation context

As you are already well informed about how to play cards during the voting phase, let's take a closer look at the feature located just below our cards in hand. It is called estimation context.

Estimation context functionality gives game participants clues on how they may estimate similar issues.

If the voting phase starts and you haven't hovered over any cards in the deck yet, the estimation context section will be empty. It will inform you that estimation context will appear in it once you hover over a card.

For example, if you hover over a card with a value of 3, Planning Poker will look through the current project of the issue, and will show all other issues that have been previously estimated as 3. Same with the other cards.

Backlog list and estimated issues archive

In the location right under the cards in hand and the estimation context is the backlog list and the estimated issues archive. They are available in all the phases of a round.

Backlog list displays all the issues in the current game that haven't been estimated yet. You can click an issue in the backlog list to quickly view the issue info in a modal, containing its summary.

Estimated issues archive displays all the issues in the current game that have already been estimated. It displays saved estimation value of each issue to its right. You can click on the issue in the estimated issues archive to view game participants' estimations given to this issue along with the issue's summary and description.

Admin game controls

This section describes functionality that is available exclusively to the game administrator (scrum master).

Top bar menu admin's features

Along with default functionality of the top bar menu, the game's admin is capable of using the following privileges:

1. Adding additional game administrator. Once "Add additional game admin" is clicked a modal will open, containing an input to search for users in your Jira. Just start typing the user name, select a desired user from the list and confirm your choice to assign an additional game admin.

   

   
   

2. Editing game settings. Once "Edit Game" is clicked, you'll be navigated to games settings menu.
3. Editing game backlog. Once "Edit Backlog" is clicked, you'll be navigated to edit backlog menu.

4. Finishing the game. Once "Finish Game" is clicked, the current game will come to its end whether or not all the issues were estimated and all the rounds were played. If the game is finished all the estimated and not estimated issues will remain in the backlog list and the estimated issues archive as they were at the moment the game had been finished.

   Info
   title Re-openning a game
   If the game is finished, "Finish Game" button is replaced by "Re-Open Game" button. You can re-open a game anytime you want by clicking this button. Re-opening a game doesn't mean stripping previously saved estimations in a re-opened game's backlog. The game's admin will have to replay rounds manually to re-estimate each issue with a previously saved estimation.

   
   

5. "Sound On/Off" button, which toggle sound of estimation timer.

6. Going AFK. Once "AFK" is clicked, the game admin will no longer participate in a current game. Although in some aspects going AFK by the game's admin is similar to going AFK by any other game player (a spectator unable to play cards, a round or a game is finished if the last participant changed role to a spectator), it affects the game flow in a very different manner.

   Note
   title Admin going AFK
   This is useful when the game admin does not participate in the voting, yet wants to control the flow. This way, they can go AFK and disappear from the participants' list, but still be able to choose which issue to estimate next, which estimation value to set, etc.

   
   

Kicking a player via the sidebar

By simply clicking on a participant's name, a modal will pop up asking to confirm the action of kicking a player.

Once the player is kicked, the card they had played is discarded.

Admin can kick a participant during the backlog, voting, or discussion phases.

Spectators cannot be kicked, as they are not displayed in the game participants list.

If each player who hasn't played their card is kicked, the voting phase would over and the round would go to its discussion phase.

Resetting estimated points counter

When an estimated value is saved at the end of a discussion phase, it is added to the sum of estimated points counter, displayed in a sidebar.

Estimated points counter is a vivid tip, allowing a scrum master to consider how much story points have been already generated by the issues estimated during the game, to compare the sum of estimated points with team's velocity and to consider a sprint to come.

To make this tool comprehensive, it is important to have a possibility to reset an estimated points counter to zero. The admin may do so by clicking on the estimated points counter. Once the estimated points counter is clicked, a modal with a reset confirmation appears. If reset is confirmed the sum displayed will be set to zero.

Backlog phase admin actions

As it was stated before, the backlog is the only round's phase where admin takes actions single-handedly. Therefore, backlog phase screen contains game controls available only to the game admin. During the backlog phase it will provide the administrator with the following capacities:

1. Re-importing backlog for current JQL. When a game is created or its backlog edited later, admin uses JQL to search Jira projects for issues they want ta add to the game's backlog. In other words, when editing a backlog, admin uses numerous filters via Planning Poker to build a JQL-query in order to add issues to the game backlog. This JQL-query is saved as one of the game parameters subsequently. If later on in the game some of the issues were deleted (for example, by "Skip & remove" admin action) or added (for example, by quick-adding in a voting phase) it's not necessary to go to backlog editing menu in order to restore the initial backlog list. Game admin can quickly restore the backlog right during the backlog phase by using "Re-importing backlog for current JQL" feature: issues in the JQL-query will be added to the game if absent; issues out of the JQL-query will be removed from the game if present.

   Info
   title Keeping estimated issues intact
   You may use "Re-importing backlog for current JQL" freely, as it won't affect any issues that have been already estimated during your game, whether or not they had been quick-added during this game.

   
   

2. Choose an issue to estimate during the current round. In issues list admin selects issues to estimate in any order they consider it suitable. Once "Estimate" button clicked in front of a selected issue, a round will go to its voting phase.
3. Quick-adding issue from Jira. This input allows game admin to type a key (e.g. JRCS-10) of an issue they want to add to the game backlog. After typing an issue key, admin either adds the issue to the top of the game backlog list by clicking "Add to backlog" or immediately starts the round voting phase on this issue by clicking "Estimate now".

Voting phase admin actions

The game administrator will be provided with a group of additional controls, available to them during the voting phase. These controls will allow game admin to commit the following actions:

1. Force opening the cards, that have been played, whether or not each game participant had played their card. Once the "Open cards" button is clicked, the voting phase comes to its end and discussion phase starts. Estimations of the players who haven't played their cards won't be taken into consideration during discussion phase;

2. Creating a sub-task for the issue at hand. Once "Create sub-task" button is clicked, a modal opens, allowing you to provide the summary and description for the new sub-task.
    

   Info
   title Immediate estimation option
   If the checkbox in your sub-task creation modal is checked, just like on the example above, a newly-created sub-task will be placed straight to the top of your game's backlog list in order to be estimated in the next round of your game. If the checkbox is left unchecked, newly-created sub-task won't be added to your current Planning Poker game. It will be added to the list of issues of your Jira project instead.

   
   

3. Starting countdown timer, in case if the voting phase lasts too long or game participants have to be hurried up in order to make their decisions faster. Once the countdown timer runs to its end, all cards are opened and the round goes to the discussion phase.

   Info
   title Tweak your timer
   45 seconds is just a default timer duration. You can customize it in your game configuration by specifying any duration you want in seconds.

   
   

4. Skipping & postponing current voting phase. Once "Skip & postpone" button is clicked, discussion phase of a round will not start and the game will go to the next round's backlog phase. The postponed issue will be moved to the bottom of the game backlog list.

5. Skipping the current voting phase and removing the issue from the game backlog. Once "Skip & remove" button is clicked, discussion phase of a round will not start and the game will go to the next round backlog phase, in case there are more issues to estimate in the game backlog. An issue that has been estimated during the skipped round would be removed from the game backlog list. If skipped and removed issue has been the last remaining to estimate in the game backlog list, the game will finish.

   Note
   title Removing from Planning Poker backlog only
   When you remove an issue from the game backlog it remains in Jira backlog intact. You may return removed issue to your game backlog with the help of re-importing JQL, or in any other way whenever you want.

   
   

6. Quick-adding issue to a game's backlog. This tool is similar to quick-adding an issue from Jira in a backlog phase. "Quick add" input allows game admin to type a key (e.g. JRCS-10) of an issue they want to add to the game backlog. Once the issue is added to the game backlog, it is moved to the top of the backlog list.

Discussion phase admin actions

1. Input to enter and save the final estimation value. This action is a pinpoint and the main purpose of the discussion phase. All the game participants have to come to an agreement upon the estimation value, that must be assigned to the issue at hand. Once an estimation value is entered and "Save estimation" button is clicked, this estimation is saved as an issue parameter and the game goes to the next round if there are more issues to estimate in the game's backlog. If an estimation value is saved for the last issue remaining not estimated, the game finishes.

   Note
   title Match your deck type with a storage field
   In order to save an estimation correctly, you have to be aware of the data type so that it may be saved to the Jira issue field. The Jira issue field to export your estimates to is set in your game's configuration. If you want to use a deck type with the export field that is not matching to its data type, make sure to configure a proper deck mapping.

   
   

2. "Replay" button allows game admin to restart the voting phase of the current round. Once clicked, all participants' estimations in the current round are discarded.
3. Participants' estimations are grouped by cards according to the game's deck type and are also an active controls element for the game admin. Once admin hovers the estimation button in this section, the estimation context section is triggered into work.
4. Suggested and average estimation overview, to simplify the decision-making process for the game admin. Suggested estimation will show the estimation value which was picked by most of the players during the round's voting phase. Average estimation will display an average estimation value, based on all the estimations played during round's voting phase.
5. "Skip & postpone" and "Skip & remove" buttons will work the similar way as during the voting phase.
   

Quick-estimating from a backlog list

Just like for a regular participant, the backlog list is available for the game admin during all the round's phases. Besides quick-viewing an issue details the backlog list also allows game admin to quick-estimate the issue they are currently viewing.

Once an issue in the backlog list is clicked a modal appears, displaying a quick issue's info, and containing "Estimate now" button. If this button is clicked, the current round ends and the new round's voting phase starts immediately, in order to estimate an issue selected in a backlog list. The current issue is postponed to the top of a game's backlog list.

Re-estimating and removing issues from the estimated issues archive

Along with viewing estimation history, estimated issues archive allows game admin to re-estimate issues in a game or removing issues from a game's backlog. Once an issue is clicked in an estimated issues archive, modal appears, containing an estimation history and the two buttons:

1. "Estimate now" button. If this button is clicked, the current round ends without any additional confirmation prompts and a new round's voting phase starts immediately, in order to re-estimate an issue selected in an estimated issues archive. The current issue is postponed to the top of a game's backlog list.
2. "Delete" button. If this button is clicked, the issue will be removed from an estimated issues archive. It won't affect a current round flow anyhow, but the deleted issue will be no longer be present in the estimated issues archive. The deleted issues estimation value will be deducted from estimated points counter in a sidebar.

This chapter has covered most of the actual game procedure in detail. One more thing, that remains to be explained, is editing the game backlog which is a brief but a standalone topic. The next chapter on this Guide will be dedicated to this topic.

Exporting a game to CSV format

When the game is finished you can export it to CSV format with summarised estimation data.