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.
The dashboard will list all the recent games created within your Jira. |
Via a list of Recent Planning Poker Games on the app dashboard you can:
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.
Although Planning Poker is an extremely potent tool to build your team's estimation process upon, it doesn't provide players with a built-in communication solution. This is because different teams prefer different communication methods. That is why it is a must for your scrum master (or another person responsible for carrying out estimation duties) to gather all the players in one meeting room, Slack channel, Skype conference, or any other suitable tool. Make your communication effective and you will succeed with your estimations! |
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:
See below for more details about each 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.
The backlog phase may be performed automatically in the background without the game admin's manipulations if round autostart was enabled in a game configuration. In this case, an issue to be estimated in the next voting phase is picked from the top of a backlog list. |
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:
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.
If cards are not opened and the voting phase is still in progress, you can replay your card by just clicking another one or by clicking the same card and confirming "Take it back" action in a modal. |
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.
Most probably you are well aware of the basic Scrum concept that while estimating an issue each participant has to be encompassed only by their own anticipations and predictions, and to deliver the estimation value of the particular issue independently. This is exactly why cards in the voting phase are held face down until the very last moment: to secure your judgment about an issue from your other colleagues who are currently estimating it. There will be a discussion phase too, dedicated to the opinions exchange. |
Once every game participant has played their card, the voting phase comes to an end.
The voting phase also ends if either:
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.
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:
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.
The Planning Poker game ends if:
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
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.
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:
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:
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:
Additionally, the sidebar hosts:
Please be informed that "Estimated Points" will be displayed only if your game is set to use deck type with integers on cards' fronts (i.e. Fibonacci deck or a custom deck with integers). |
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:
"Edit issue" button, which allows viewing and editing any issue and performing standard Jira actions in a modal window;
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. |
"Get updated issue data from Jira" button, which gets the latest info about the issue;
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. |
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.
Estimation context is a highly advanced and very powerful feature of Planning Poker app. To get to know more about it, you should look in "Game flow" article in "Game start and configuration" chapter of this Guide. |
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:
This section describes functionality that is available exclusively to the game administrator (scrum master).
Along with the default functionality of the top bar menu, the game's admin is capable of using the following privileges:
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.
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.
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. |
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.
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. |
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.
Fear not. Kicking a player is not a permanent measure. A kicked player will be dropped to the Planning Poker dashboard. They will be able to reconnect anytime from the dashboard or with the help of an invitation link. |
By clicking their own name in a sidebar, an admin will initialize a process of kicking himself. Think of it as an optional way to go AFK (or: go AFK like a boss!). |
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.
Estimated points counter is just a tool which makes it convenient to track the sum of your estimated values. It keeps the sum of estimated values in separate storage. This means that when estimated points counter is reset, all the saved issue's estimated values remain untouched. |
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:
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.
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. |
Remember, if "Round autostart" option is enabled in a game configuration, the backlog phase will be skipped as a whole except for the very first round of a game. Check your game configuration, if you're expecting to select the next issue to estimate manually. |
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:
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.
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. |
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.
45 seconds is just a default timer duration. You can customize it in your game configuration by specifying any duration you want in seconds. |
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.
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.
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. |
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.
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. |
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.
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:
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.
When the game is finished you can export it to CSV format with summarised estimation data.