Agile Poker: Planning Through Cards

Instructor: Dwayne Brathwaite
Planning poker is an estimation technique used in the scrum framework. It is meant to clarify how complex user stories are and ensures the team isn't being over-committed.

Planning Poker

In the scrum framework, planning poker is used to estimate the effort required to complete the work in user stories. A user story is a tool to describe a new software feature to the user. These user stories will be used in planning future work. The Scrum team, which at a minimum includes a product owner (the representative of the primary stakeholder or customer) and the development team, are the participants in planning poke. The role of the product owner is to present the user stories to the rest of the team. The development team's role is to ask clarifying questions to ensure the requirements are understood well-enough to estimate the effort - and to estimate those user stories for the product owner when prompted to do so.

Goals of Planning Poker

Planning poker is intended to estimate all the user stories that are being prepared for future sprints. A sprint is a set time-period of typically 2-6 weeks where set tasks must be completed for delivery to the customer. To ensure that the work of the sprint is manageable for the development team, each feature in the sprint, represented by a user story, is discussed and estimated. This gives the product owner or customer the ability to include the maximum amount of features (how the software looks or behaves or what it can do) the team can complete within the sprint - and no more. As you can imagine, some features are more complex than others, so poker is important in ensuring that the development team isn't over-committed.

Poker Process

Just like real poker, planning poker was originally played with playing cards. Teams today often use apps and other devices for estimating as well. During planning poker, the team discusses the complexity of each feature, possible technical approaches, how long they believe it'll take to implement the feature and any assumptions that must be further broken down. The discussion of each item can also be time-boxed to limit the time spent on these complex issues. The team poses questions to the product owner (or their representative in the planning session).

Poker cards in hand

At the end of the discussion, the development team selects the 'card' representing their estimate for the user story just discussed. This is done after a brief countdown. The entire team reveals their estimate simultaneously to reduce bias - and one can assume, peer pressure!

Based on the reveal process, it's more than likely that the development team will have differing estimates. This is an opportunity for the product owner to solicit further feedback from the members with the highest and lowest estimates. Their insights will help guide further discussion on the user story and then the team estimates again. This continues until a consensus estimate is reached.

To unlock this lesson you must be a Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use

Become a member and start learning now.
Become a Member  Back
What teachers are saying about
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account