Planning Poker - Quick Start Guide

Thank you for using this first iteration of Easy Agile’s planning poker functionality. This has been provided as part of your TeamRhythm licence.

Use case

The purpose of this planning poker action panel is to provide a means to collect a numerical estimate of effort from anyone viewing the ticket, and to provide an average calculation of the estimates provided so far.

What planning poker does today

The planning poker feature allows any logged in user viewing the ticket to cast their vote with regards to the effort required to get the ticket done. The vote cast can be any integer greater than or equal to zero.

A user can re-cast their vote as many times as they like - any previously entered value will be overwritten.

The planning poker panel will show the avatars of everyone who has voted, with their votes initially hidden.

Clicking on the “show votes” toggle button will unhide all the votes and provide a calculation of the numerical average. There is no restriction on how often or how many times the “show votes” toggle button can be clicked.

There is no restriction on when a vote can be cast ie. there is no concept of a planning poker session needing to be started before voting can occur. Teams are free to decide how they will use the planning poker panel i.e. in a dedicated session or asynchronously.

How to use planning poker

The asynchronous approach

Users can leave their estimate on how much effort a particular issue will take at any time they choose. Easy Agile recommends this approach should be taken for the issues that are straightforward and just-do-its. These issues would have been previously debated or already broken down into their smallest possible slices.

A scrum master may choose to review view the submitted estimates at any time and use that as a basis for their accepted story point estimate.

The structured estimation session

A structured estimation session is best used when:

• the issue is new and may not be widely understood by the team yet;
• estimates provided so far are too big or show a wide spread of values.

The session would provide opportunity for the team to discuss the issue and ask clarifying questions before submitting their revised estimate.

Combining the two approaches

1. Shortlist the issues the team would consider taking on in an upcoming sprint
2. Allow the team to submit estimates that they believe are straightforward and just do its in their own time. This could be a couple of days before the next estimation session. The tech lead can autonomously review the issues that are being estimated to see if there is general agreement with regards to effort.
3. Issues that have general consensus with their story points can be considered “done” and can be put aside during the scheduled estimation session.
4. Issues that are contentious with either extremely large or a wide variance of estimated effort can be discussed during the estimation session where the team is in attendance.

Please submit your planning poker related feedback here.

What planning poker doesn't do (yet)

Current limitations of the planning poker panel include:

• There is no access/permission check on who is allowed to cast a vote
• There is no access/permission check on who is allowed to show/hide cast votes
• There is no functionality provided to manage a planning poker estimation session
• There is no way for a user to remove their vote once it is cast
• There is no ability to configure how votes can be cast e.g. t-shirt sizing, Fibonacci sequence
• The average calculated is a basic mathematical average calculation rounded to the nearest integer
• There is no support for a shared session/view for planning poker estimation interactions i.e. all users will need to click from issue to issue themselves

Known issues around "Copy to issue's Story Points" functionality

Issue #1

Click on the message directly to see more detail about why the message might not be updating.

Issue #2

This functionality requires the story points field to be visible in the Jira issue viewer and be editable by your user.

Recommended action is to speak to your Jira or project administrator to check these settings.

Issue #3

This issue appears for issue types that don’t support estimation tracking, such as epics or higher level issue types. This typically occurs on company managed projects, however this will depend on your issue configuration.

Recommended action is to speak to your Jira or project administrator to verify your issue configuration.

Issue #4

This is the default error for Atlassian Jira API errors.

Recommended action is to speak to your Jira or project administrator to validate that the project and issue configurations support story point estimation.

Issue #5

Currently the “Copy to story points” function is only supported on Scrum only boards (can be either team or company managed).

Recommended action is to switch board types if possible, or manually enter the value into the issue’s story points field.

Issue #6

This feature is not supported within Kanban projects, as Kanban frameworks generally do not support the idea of estimation.

Recommended action is to manually set the story points field if it is being used.