agile poker

Online Planning Poker for Remote Teams

The COVID-19 pandemic has affected business worldwide as mandates on staying at home were put in place. Those businesses that could switch to remote work did so quickly as working from home became the new normal. Some are predicting it could cause a permanent shift in remote working as businesses learn to set up remote working procedures and processes. 

If your company is working in an agile methodology, as we do in our lean agile formula for digital innovation delivery, you may be aware that planning poker is an important part of the process.

What is Planning Poker?

Planning poker is a consensus technique widely used in agile software development in which a group estimates the level of complexity for a particular GitHub issue. Each member of the group gives their estimate in a poker-style game in which the reveal happens at the end. A lot of companies use this technique in person, in a meeting, with actual cards.

A project is essentially broken down into feature requests and tasks by writing user stories that break up the work into smaller manageable chunks. Planning poker sessions commence when two or more members of a project team convene to estimate the complexity of a user story. 

User stories are objectives a user should be able to achieve with the product. Each user story is further defined by acceptance criteria (AC), a checklist of requirements needed to complete the user story. Internally, we also refer to them as tickets or issues. 

Can I Do Planning Poker Remotely? 


At Revelry, we’ve had a remote-friendly policy since the origins of the company 7 years ago. Through the years, we’ve learned from our mistakes, minimized friction, and honed our tools and processes, making way for pretty innovative methods for getting work done remotely.  

Our online planning poker is set up for asynchronous remote teams. We have our own custom-built Slack bot where folks can jump into planning poker easily.

Want to know even more about our process?

Go for a deep dive into the Lean Agile Process at Revelry.
Get in touch and let us know what we can build with you.

Planning Poker for Remote Teams

Online planning poker can be done asynchronously or together if someone calls out a session and everyone is free to join. Just like in person, everyone scores the issue and once the driver—the person running the poker session—determines everyone has weighed in, they reveal the scores. Arguments are made and risks are evaluated until a consensus is reached. 

The nice thing about this method is that people can add notes along with their score and these notes can be copied directly over to the ticket comments. No need for anyone to take meeting notes!

Now let’s tackle some frequently asked questions about planning poker.

Planning Poker FAQ

Q. What are Story Points?

A: Story points reflect the level of complexity and effort associated with delivering the story based on the acceptance criteria. All work required for delivering the issue to completion counts towards the complexity. This work includes getting clarity on the issue, product management, development, writing tests, design, QA, UAT, release to production, and any other effort to deliver the new feature. 

At Revelry, we use the Fibonacci sequence range of 1, 2, 3, 5, 8, 13 to assign story points. Story points increase as complexity increases. Though story points reflect the level of complexity and effort associated with completing the ticket, story points do not reflect the amount of time to deliver the feature. Instead, we estimate effort.

Q. Why Do We Estimate Effort?

A: We estimate the effort of completing a ticket for a couple of reasons. 

First, it lets the team voice the complexity of effort which goes into completing the user story. The complexity isn’t reflected in time. As a team works through sprints, the number of story points from tickets that are completed at the end of a sprint is tallied. This tally is put into an average over a number of sprints and reveals the velocity at which the team can complete issues in a given sprint. 

The velocity is a second benefit of estimating effort through story points. By referencing the velocity, the Product Owner and Product Manager can leverage the velocity during sprint planning to select a range of tickets that have the total story points value which approximately equals the team’s velocity.

Referencing the example below, you can see five completed sprints in blue. Each sprint contains a number of story points that were completed. By averaging the number of story points completed during the previous three sprints, we can see a trend in the green of the velocity. The Product Manager and Product Owner can use the velocity of 15 when planning sprint 6.

Q. Why Aren’t Story Points Measurable in Time?

A: This question gets asked on a lot of projects. Let’s break this down by an example. We have a user story that has been given a story point value of 5. On our project, a 5 reflects moderate effort. This user story took 10 days to go from “In Progress” and through “UAT”. How does that make sense? Let’s look at the details.

The user story required an engineer to populate new tables with certain data. After the actual implementation work was completed, the engineer had to monitor and analyze the data for a period of time to confirm the new tables were collecting what was intended. The level of effort was still a 5 for changes but extra time was required to test and confirm success.

So, the reason this user story took longer in time compared to other user stories which had a similar effort is due to the time box. All of the effort was accurately captured in the score of 5.

Q. How Do We Assign Story Points?

A: We use our poker bot in Slack. 

Using the poker bot commands, the driver begins the session:

  • The driver fires up the first ticket once the team is ready using the command /poker start repo/xxx and the ticket content shows in Slack.
  • Each person participating submits a score privately in their Slack using the command /poker estimate [x] [comment].
  • We use the Fibonacci sequence range of 1, 2, 3, 5, 8, 13 to assign story points. Story points increase as complexity increases. All of the work counts for the complexity score. Getting clarity on the issue, project management, development, writing tests, design, QA, UAT, release to production, and any other work all count for the complexity score!
  • Whenever possible, we break out user stories which receive 13 points into at least two smaller tickets.
  • Slack shows the names of everyone who has submitted a score.
  • The driver uses the /poker reveal command to show submitted scores.

The team discusses their scores, which may result in:

  • a comment on the ticket 
  • an implementation note added to the background
  • revised AC
  • consensus

Once a consensus has been reached, the driver uses the /poker decide [x] command to set the point value for that ticket. The label points x will automatically be added to the ticket.

Q: What Happens if Tickets are Rejected?

A: In some instances, a user story can be rejected during poker. A user story is rejected when AC isn’t clear enough, the team finds the ticket should be broken into smaller units of work, or the foundations of the AC are unknown and the team needs to investigate further. To combat tickets being rejected in poker, Revelry does a “pre-poker” where engineers look at tickets with a draft label and add notes or requests for clarification from the PM. We use another internal kanban product and look at the estimate column before the poker begins.

Q: What if We’re Stumped on Reaching Consensus on Story Points?

A: If the team is unable to immediately decide the effort of an issue, but feel the background and AC is sufficient, we use the triangulation of previously closed issues. 

Triangulation is when we take the ticket in question and compare it to two other tickets of varying complexity to see how this issue compares to the completed tickets. Then, the team will score the ticket again until consensus is reached.

If the background and AC are unclear, the team can @mention the Product Manager and/or Product Owner in the project Slack channel to have them join the discussion. If more work needs to be done on prepping the issue, the team can ultimately reject the issue in poker and assign it to the PM/PO in GitHub and ask for clarification in a ticket comment.

Q: How many days does it take to complete a story point?

A: Story points are a reflection of the effort involved in working an issue. This effort is not measured in days. A seasoned engineer familiar with the problem may take 2 hours on a 5 point issue whereas a junior level engineer could take multiple days. It all depends on the specific problem and circumstance. However, the actual complexity remains the same.

Q: How many folks are required to start a poker?

A: Two is good. Three or more is better. When deciding who should attend a poker, consider the context of the work. If the ticket is a design story, then at least one designer should participate. If the work is implementation, then one or more engineers should participate.

Q: Who is required to attend a poker?

A: Two team members. That’s it. The Product Manager and Product Owner are not required to attend.

Have more questions for us? Let us know on Twitter!