A Practical Guide to Planning Poker

Step 1: The Kick-off - What Are We Estimating?

Estimation isn't about predicting the future; it's about creating a shared understanding. Let's imagine a team is building a new e-commerce website. The Product Owner presents the first user story:

'As a customer, I want to view a list of products so that I can decide what to buy.'

Key Takeaway: The entire team should discuss the story until everyone is clear on the requirements. What's included? What's not? For this story, it's just viewing products, not searching or filtering.

Step 2: Establish a Baseline - Your First Anchor

Your first estimation is the most important because it sets the scale for everything else. This is your 'reference story'. The team discusses the 'View Product List' story. It involves a database query, a simple UI grid, and loading product images. It feels like a small, but not trivial, amount of work. After some discussion, the team agrees to call this a 3-point story.

The 'View Product List' story is now your reference. All future stories will be compared to it. Is it bigger than a 3? Is it smaller?

Key Takeaway: This first estimate creates an 'anchor' for relative sizing. It's less about the number itself and more about the team's shared agreement on the effort it represents.

Step 3: The First Round - Relative Sizing in Action

Now for the next story: 'As a customer, I want to add a product to my shopping cart from the product list page.' The session owner sets this as the current story in Agile Estimate. Everyone quietly considers the work involved compared to the 3-point reference story.

Key Takeaway: This involves creating a cart in the user's session, adding an item, and giving feedback in the UI. It seems like more work than just displaying a list. Each team member selects a card that represents their estimate.

Step 4: Reveal and Discuss - The Core of Collaboration

The owner clicks 'Reveal Votes'. The votes are shown: two developers voted 5, but one senior developer voted 3. This is where the magic happens. The team members with the highest and lowest estimates explain their reasoning.

The senior dev says, 'We already have a cart service, so it's just a simple API call.' The other dev replies, 'I was thinking about the UI state management and showing a confirmation toast, which adds complexity.'

Key Takeaway: The discussion isn't about who is 'right'. It's about uncovering assumptions and sharing knowledge. Through this conversation, the team gets a clearer picture of the actual work involved.

Step 5: Reach Consensus - Vote Again

After the discussion, the session owner clicks 'Reset Round'. The team votes again on the same story. This time, informed by the new information, everyone feels more confident. The new votes are revealed: everyone has voted 5.

Key Takeaway: Consensus is reached! The team agrees the story is a 5. This new story can now also serve as a reference point for future estimates.

Step 6: Using Special Cards - The '?' and '☕️'

What if a team member is completely unsure? They can use the '?' card. This is a powerful signal that they don't have enough information to estimate. It immediately prompts a discussion to clarify the story.

The '☕️' (coffee cup) card is for when a team member feels they need a short break. It's a fun way to keep the session flowing and ensure everyone stays focused.

Key Takeaway: These cards are tools for better communication, not just for estimation.

Step 7: Keep the Flow - New Round and History

With the 'Add to Cart' story estimated, the owner clicks 'New Round' to move to the next item in the backlog. All previous rounds are saved in the 'Round History' at the bottom of the page, including the stories and the final average estimate. This provides a valuable record of the team's decisions.

Key Takeaway: Planning poker is an iterative process. Each round builds on the last, improving the team's collective understanding and the accuracy of its forecast.