The COVID-19 pandemic affected businesses worldwide as work from home mandates were put in place. Organizations that could shift to remote work did so quickly and – voila! – dispersed workforces became the new normal. Today, thousands of businesses across a variety of industries have employees working outside of the office. If yours is one of them – and relies on an agile methodology, as the software development team at Revelry does – you know planning poker is an important part of the process. (And there’s an opportunity for product engineering teams to reimagine how it’s done.)
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?
Absolutely.
At Revelry, we’ve had a remote-friendly policy since the origins of the company more than a decade ago. Through the years, we’ve learned from our mistakes, minimized friction, and honed our tools and processes, making way for a variety of innovative methods for getting work done – even when we’re in different parts of New Orleans, in different states, and in different time zones.
Our online planning poker is set up for asynchronous remote teams. We use our custom-built Slack bot, so folks can jump into planning poker easily (and from anywhere!).
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 each team member has weighed in, the scores are revealed. Cases are made and risks are evaluated until a consensus is reached.
The nice thing about online planning poker is that people can add notes along with their score and these notes can then be copied directly over to the Github ticket comments. Boom! No need for anyone to take meeting notes!
Now, let’s tackle some frequently asked questions (FAQs) 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.
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/xxxand 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, 13to 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
13points into at least two smaller tickets. - Slack shows the names of everyone who has submitted a score.
- The driver uses the
/poker revealcommand 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 can’t reach 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 session?
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 planning poker session?
A: Two team members. That’s it. The Product Manager and Product Owner are not required to attend.
Have more questions for us? Connect with a member of our team.
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.