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. Use the copy link option to share or join the game.

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 the game link from an invitation email sent by the game 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

The 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 roles: game admin or regular participant, player or spectator. But the core goal of this phase is simple: the admin and the players should give their estimates for the issue of the current estimation round. And this is how it happens.

Each player (except spectators) receives a number of cards to their hand, depending on the deck type selected during the game configuration. Typically, your cards in hand will look like this:

1. The 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 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 to open 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 as 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

The discussion phase is the conclusive stage of the round and embodies its positive goal: to give the final estimation for 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 by the scrum master, have to come to a 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 chart shows estimation along with so-called "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 of the round.

If a certain estimation value of an issue has been agreed upon, the game administrator submits it. After the 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 are 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 image. A finished game may be re-opened again. 

Estimated issues may be opened in the Advanced issue search for further editing/bulk editing

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 the game 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. New Game: A button that allows you to start a new game;
2. Search: A text input that allows you to filter games by description, owner, or state. Just start typing your desired filter, and the games list will be affected immediately;
3. Game state and Creator filters: dropdown lists, that allows you to filter estimation games.
   1. Switch between whether finished games should be displayed or not. The option to hide finished games is enabled by default;
   2. Filter games of a specific creator;
4. Join: the button that allows you to join a game as a participant;
5. Clone game: 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. Copy game URL: 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. Mobile version: A button that allows accessing Planning Poker games from a mobile view, providing estimates. The estimation from mobile is optimized for in-room estimation when a moderator shares their screen. 

Top bar menu

When you hop from the Planning Poker dashboard into the game, in all rounds' phases you'll be accompanied by 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. "Sound On/Off" button, which toggles the sound of the estimation timer.
3. "Become spectator" button changes your status from the game participant to the spectator. Once you've become a spectator, the button will change its state to "Become participant", allowing you to return to the game if there are participants with cards to play. If you are the last participant to play their card and you switch to the Spectator role, the voting phase of the round ends.
4. "Share game" option copies the game link to be shared with other participants through a variety of communication channels. 

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:

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 game spectators.

Additionally, the sidebar hosts: 

1. An estimated points counter with a total of estimation points given to issues during the game.
2. The timer if it's enabled;
3. Ability to switch participant's role to/from Spectator
4. Ability to switch other participants' roles to/from Spectator (only for game admins)
   
   

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. "Edit issue" button, which allows viewing and editing any issue and performing standard Jira actions in a modal window;

   Players can edit

   Please 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.

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

   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.

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

Game backlog (unestimated issues) and Estimated items list are located right below the game cards and the estimation context. 

Both areas have expanded and collapsed views with the Backlog being expanded by default, while Estimated items are collapsed from the start.

Switch between the views by using icons on the right from headers: 

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 the default functionality of the top bar menu, the game's admin is capable of using the following privileges:

1. Change game administrator. Once Change game administrator 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. Game configuration. Once Game configuration is clicked, you'll be navigated to games settings menu.
3. Backlog configuration. Once Backlog configuration is clicked, you'll be navigated to edit backlog menu.
4. Restart game leads to a complete replay of the game from the scratch. 

5. Finish 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.

   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.

6. "Sound On/Off" button, which toggles the sound of the estimation timer.

7. 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.

   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.

   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 the game admin to commit the following actions:

1. Open cards. 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 the discussion phase starts. Estimations of the players who haven't played their cards won't be taken into consideration during the 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.
    

   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, the 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 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.

   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 the 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, the 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.

   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 on the estimation value, that must be assigned to the issue at hand. Once an estimation value is entered and the "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.

   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 the 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 the admin hovers the estimation button in this section, the estimation context section is triggered into work.
4. Suggested an average estimation overview, to simplify the decision-making process for the game admin. The suggested estimation will show the estimation value which was picked by most of the players during the round's voting phase. The average estimation will display an average estimation value, based on all the estimations played during the round's voting phase.
5. "Skip & postpone" and "Skip & remove" buttons will work a 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 procedures 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 of 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.