Estimating with Story Points and Planning Poker

Introduction

In our last lesson, you mastered the art of crafting high-quality user stories using the INVEST framework. We focused on making stories that are Independent, Negotiable, Valuable, Small, and Testable. Now, we'll turn our attention to the "E" in INVEST: making stories Estimable. This is a crucial step that transforms a well-defined requirement into a piece of work a team can realistically plan and commit to.

This lesson will equip you with the techniques used by high-performing agile teams to estimate work effort. We will first demystify story points, explaining why this relative measure of effort is more effective than estimating in hours or days. Then, you will learn the step-by-step process of Planning Poker, a collaborative and surprisingly effective technique for reaching a consensus on estimates. For you, as an aspiring senior developer and manager, mastering estimation is not just about assigning numbers; it's about fostering shared understanding, identifying hidden risks, and enabling your team to make predictable forecasts.

1. The Principle of Relative Estimation: What is a Story Point?

Before we can estimate, we must agree on what we are measuring. In agile, we separate the size of the work from the duration it takes to complete. This is one of the most fundamental shifts from traditional project management.

Mike Cohn, a key figure in the Agile community, provides an excellent explanation of this core principle: "estimate size, derive duration."

{"type":"video","title":"Agile Estimating | What Makes a Plan Agile? [Plus Story Points & Planning Poker]","learning_duration":599,"video_id":"37zfyncCpkA","par_intro":"This excerpt from a talk by Mike Cohn introduces the foundational concept of separating size from duration using simple, real-world analogies.","par_directions":"Watch the segment from <span data-type=\"resource_video_timerange\" data-resource-subitem-id=\"601473a8\" data-range-start=\"153\" data-range-end=\"752\">the start of his estimation exercise</span>. Pay close attention to his examples of driving to Paris and reading a Harry Potter book. The key takeaway is the distinction he makes between the size of a task (e.g., pages in a book) and the time it takes to complete it (which depends on your reading speed, or \"velocity\").","video_duration":3501,"isV2":true,"blockId":"4e722d7f-4850-4246-b65a-7ef5f78bc803","lessonId":"5516ddcf-8bb6-4ef3-bad5-f5d4e8100810"}

As Mike Cohn explains, story points are a unit of measure for the size of a user story. A story point is a relative value that represents the overall effort required. This "effort" is a combination of three factors:

1. Volume of Work: How much is there to do?
2. Complexity: How difficult is the work? Are we dealing with a simple CRUD operation or a complex algorithm?
3. Risk & Uncertainty: What are the unknowns? Are we using a new library? Is the requirement ambiguous?

A common mistake is to think of story points as just "complexity points." They are not. A task can be simple but involve a large volume of repetitive work (e.g., "licking a thousand stamps"), while another can be complex but quick to implement (e.g., "simple brain surgery"). If they take a similar amount of overall effort, they should have a similar story point value.

To make this concept of relative sizing more concrete, let's practice with a non-technical example.

{"type":"video","title":"Agile Estimating | What Makes a Plan Agile? [Plus Story Points & Planning Poker]","learning_duration":794,"video_id":"37zfyncCpkA","par_intro":"In this segment, Mike Cohn leads an interactive exercise using \"Zoo Points\" to demonstrate how relative estimation works in practice.","par_directions":"Watch the exercise from <span data-type=\"resource_video_timerange\" data-resource-subitem-id=\"b46cb5af\" data-range-start=\"1226\" data-range-end=\"2020\">Zoo Points</span>. Notice how the group establishes a baseline (e.g., a lion is a '1') and then estimates other animals *in relation to that baseline*. This is the essence of how story points work.","video_duration":3501,"isV2":true,"blockId":"e1f8dd3c-f829-447d-a10f-d63dcf5a4dc9","lessonId":"5516ddcf-8bb6-4ef3-bad5-f5d4e8100810"}

The "Zoo Points" exercise highlights a key benefit: relative estimates are easier for a team to agree on than absolute time estimates. You and a senior colleague might disagree on whether a task takes 5 hours or 8 hours, but you can both likely agree it's about twice as big as another task.

{
  "type": "exercise",
  "id": "b5233632-c722-4962-803b-bb3cc01ac4fd"
}

2. The Fibonacci Scale: Why We Use 1, 2, 3, 5, 8...

When assigning story points, teams don't use a linear scale (1, 2, 3, 4, 5...). Instead, a sequence inspired by the Fibonacci numbers is most common: 0, 1, 2, 3, 5, 8, 13, 21...

The reason for this is to reflect the inherent uncertainty in estimation. The difference between a 1 and a 2 is significant. The difference between a 7 and an 8 is not; debating it is a waste of time. The widening gaps in the Fibonacci scale force us to make meaningful distinctions. If a story doesn't feel like a 5, but it's clearly more than a 3, it must be a 5. This prevents false precision.

Given your computer science background, you might appreciate that there's a mathematical elegance to this. The ratio between consecutive Fibonacci numbers converges to the golden ratio ($\approx 1.618$). This means the scale reflects a consistent, exponential-like growth in perceived effort, which often mirrors how complexity scales in software.

{"type":"reading","par_intro":"This short academic paper provides a formal look at why the Fibonacci scale is so effective for agile estimation, connecting it to the golden ratio.","par_directions":"Skim through **Section 3.4, \"A Fibonacci measure of effort\"** (<span data-type=\"resource_reading_textrange\" data-resource-subitem-id=\"97a5c2e4\" data-range-start=\"A Fibonacci measure of effort\" data-range-end=\"times more effort to complete than the story one-level below it in difficulty.\">the section starts here</span>). You don't need to follow the entire proof, but notice the conclusion: in the long run, a more difficult story is perceived as taking a \"golden ratio\" times more effort than the previous one. This provides a sound theoretical basis for the practice.","learning_duration":"5 minutes","url":"https://columbia.edu/~ask2262/Obsessions/KudinoorFibonacciStoryPoints.pdf","title":"[PDF] The Golden Rule of Agile Estimation: Fibonacci Story Points","isV2":true,"blockId":"b02898a4-d8fa-4d3f-91b6-e2af62cc00f4","lessonId":"5516ddcf-8bb6-4ef3-bad5-f5d4e8100810"}

In a practical sense, each number on the scale has a qualitative meaning for the development team.

{"type":"image","url":"https://scrumorg-website-prod.s3.amazonaws.com/drupal/inline-images/Screen%20Shot%202021-10-19%20at%2012.32.08%20PM.png","caption":"This chart translates the abstract Fibonacci numbers into concrete, developer-focused descriptions of effort, risk, and complexity. It's a useful reference for what each number typically implies.","isV2":true,"blockId":"2ecfe89d-4b81-4b04-9b25-9cf87fa930e9","lessonId":"5516ddcf-8bb6-4ef3-bad5-f5d4e8100810"}

As the chart shows, higher numbers like 13 and 21 are warnings. A story of this size is too large and risky to be completed in a single sprint. It must be split into smaller, more manageable stories—a skill you practiced in our last lesson.

{
  "type": "exercise",
  "id": "61265a8c-46c4-48f9-ade8-8d379911ea94"
}

3. Planning Poker: The Technique for Consensus-Based Estimation

Now that we understand what story points are, how do we assign them? The most popular technique is Planning Poker. It's a gamified, consensus-based approach that ensures everyone on the team participates and helps to eliminate cognitive biases like "anchoring," where the first number spoken influences everyone else.

This short, animated video gives a clear overview of the process.

{"type":"video","title":"Agile Estimating and Planning: Planning Poker ®","learning_duration":298,"video_id":"gE7srp2BzoM","par_intro":"This video from Mountain Goat Software provides a concise, step-by-step walkthrough of a Planning Poker session.","par_directions":"Watch the entire video from <span data-type=\"resource_video_timerange\" data-resource-subitem-id=\"1858f724\" data-range-start=\"2\" data-range-end=\"300\">start to finish</span>. It clearly demonstrates the flow, the importance of discussing outliers, and how to reach a consensus.","video_duration":332,"isV2":true,"blockId":"f0d15d73-6fd7-4ae8-b958-b08e41772423","lessonId":"5516ddcf-8bb6-4ef3-bad5-f5d4e8100810"}

Let's break down the steps, which are also neatly summarized in the flowchart below.

{"type":"image","url":"https://doasync.com/static/9151aa27e04574f874bb792e453dfbd9/c7a96/planning-poker-correct-steps.png","caption":"This flowchart illustrates the cyclical nature of Planning Poker, from discussion to estimation to achieving consensus.","isV2":true,"blockId":"7bfe20c3-7555-40ad-bc85-7cf67cd67f4b","lessonId":"5516ddcf-8bb6-4ef3-bad5-f5d4e8100810"}

The process is as follows:

1. Present the Story: The Product Owner presents a user story and its acceptance criteria.
2. Discussion & Q&A: The team asks clarifying questions to ensure everyone understands the scope. This is the "Conversation" from the 3 Cs.
3. Select Cards: Each team member privately selects a card from their deck that represents their estimate. This is the crucial step that prevents anchoring bias.
4. Reveal Simultaneously: Everyone reveals their card at the same time.
5. Discuss and Converge:
   • If all numbers are the same (or very close): Consensus! The estimate is recorded, and the team moves to the next story.
   • If the numbers differ: The team discusses the divergence. Crucially, the people with the highest and lowest estimates explain their reasoning. This is the most valuable part of Planning Poker, as it uncovers different assumptions:
     • The developer with the low estimate might say: "I've built a similar feature before and we can reuse this component."
     • The developer with the high estimate might say: "The database schema for this is more complex than it looks, and we'll need to do a migration."
     • The QA engineer might say: "This touches a critical part of the system and will require extensive regression testing."
6. Re-Vote: After the discussion, the team estimates again. This cycle repeats until a consensus is reached, typically within 2-3 rounds.

The goal is not to average the numbers or have the majority win. The goal is to leverage the collective knowledge of the team to arrive at a shared understanding and a realistic estimate.

{
  "type": "exercise",
  "id": "c1410527-0b87-4008-92ee-3d1e0de60ac2"
}

4. Your Turn: Run a Mock Planning Poker Session

Now it's time to put theory into practice. You'll simulate a Planning Poker session for the user stories you created in the last lesson's exercise. Since you're working alone, you will play the roles of different team members (e.g., a frontend developer, a backend developer, a QA engineer) to practice thinking from multiple perspectives.

1. Take Your User Stories: Use the two user stories you split from your epic in the previous lesson. (e.g., "Submit a review" and "See all reviews").

2. Establish a Baseline: Pick one of your stories and declare it the baseline. This is your reference point.

   • Example: "Let's agree that the story, 'As a site visitor, I want to see the average rating and all reviews for a book...' is a 3-point story. It involves a straightforward data fetch and display."

3. Estimate the Second Story: Now, use Planning Poker to estimate your other story (e.g., "As a registered user, I want to submit a rating and a text review...").

   • Simulate Round 1:
     • Persona 1 (Backend Dev): "This seems simple. Just an API endpoint to save data to the table. I vote 2."
     • Persona 2 (Frontend Dev): "There's more here. We need a form with star ratings, text validation, handling loading states, and showing success/error messages. I vote 5."
     • Persona 3 (QA Engineer): "I agree with the frontend dev. I need to test invalid inputs, authenticated vs. unauthenticated states, and what happens on API failure. I also vote 5."
   • Simulate the Discussion: Write down the key points from the "discussion." The high estimates from the Frontend and QA personas reveal work the Backend persona hadn't fully considered.
   • Simulate Round 2 (Consensus): After the discussion, the Backend developer agrees that their initial estimate was too low. The team re-votes.
     • Backend Dev: Votes 5.
     • Frontend Dev: Votes 5.
     • QA Engineer: Votes 5.
   • Conclusion: The team reaches a consensus of 5 story points.

Document this process. This exercise will serve as your "paper trail of competence," demonstrating your ability to facilitate an estimation process and think through the different facets of a user story.

Conclusion

In this lesson, you've learned the fundamental techniques for agile estimation. You now understand not only the "how" but also the "why" behind these powerful practices.

Key Takeaways:

• Estimate Size, Derive Duration: Story points measure the effort (volume, complexity, risk), not the time.
• Relative Sizing is Key: Estimate stories in relation to one another, not in a vacuum. A baseline or reference story is essential.
• The Fibonacci Scale Encourages Deliberation: The non-linear scale prevents pointless debates over minor differences and reflects the growing uncertainty of larger tasks.
• Planning Poker Builds Shared Understanding: The primary value of the technique is not the number itself, but the rich conversation that uncovers assumptions and risks.

In our next lesson, we'll look at how these estimates feed into the daily rhythm of a sprint. You will learn how to deliver concise and effective updates during daily standups that clearly communicate progress, plans, and blockers, helping your team stay aligned and on track.