Estimation Techniques - Deep Dive

Story Points (Modified Fibonacci)

The scale

1  -  2  -  3  -  5  -  8  -  13  -  21

Story points measure relative complexity, not time. A 2-point story is roughly twice as complex as a 1-point story. The gaps widen intentionally - distinguishing between a 14 and a 15 is false precision.

Anchoring the scale

Every team needs reference stories to anchor their scale. Without anchors, estimates drift over time.

How to establish anchors:

1. Pick a recently completed story that everyone agrees was straightforward
2. Assign it 3 points (the middle of the useful range)
3. Find a story that was roughly half as complex - that's your 1-2 point anchor
4. Find a story that was roughly twice as complex - that's your 5-8 point anchor
5. Document these as the team's reference stories; revisit quarterly

Example anchor set:

What story points capture

Points reflect three dimensions:

1. Complexity - How many moving parts? How many systems touched?
2. Uncertainty - How well do we understand the problem? Any unknowns?
3. Effort - How much raw work is involved?

High uncertainty alone can justify a higher estimate. A simple task in an unfamiliar codebase might be a 5 even though the logic itself is a 2.

Planning Poker

Process (detailed)

1. Moderator reads the story - PO explains the user story and acceptance criteria
2. Clarifying questions (time-box: 3 min) - Developers ask questions. No estimating discussion yet
3. Silent estimation - Each person selects a card from the Fibonacci sequence. Do not reveal yet
4. Simultaneous reveal - Everyone shows their card at the same time. This prevents anchoring bias
5. Discuss outliers - If estimates span more than 2 levels (e.g., 2 and 8):
   • Highest estimator explains their concerns
   • Lowest estimator explains what they see as simple
   • Often reveals hidden assumptions or missed requirements
6. Re-vote - After discussion, vote again. If still divergent after 2 rounds, take the higher estimate and note the uncertainty
7. Record and move on - Don't spend more than 5 minutes per story. If consensus is impossible, the story needs more refinement

Tools

• Physical cards (traditional, best for co-located teams)
• PlanningPoker.com (free, works for remote teams)
• Jira estimation features
• Slack-based bots (e.g., Polly for quick votes)

Common mistakes in planning poker

• Anchoring: Senior dev speaks first and everyone follows. Fix: simultaneous reveal
• Averaging: Taking the mean of divergent estimates. Fix: discuss and re-vote
• Time-based reasoning: "That'll take 2 days so it's 2 points." Fix: redirect to complexity, not hours
• Skipping discussion: Everyone picks the same number so you move on. Fix: still do a quick sanity check

T-Shirt Sizing

Best for early-stage estimation when stories are not yet refined enough for story points.

Scale

When to use T-shirt sizing

• Roadmap planning (quarter-level estimation)
• Initial backlog triage before refinement
• Non-technical stakeholders are in the room
• The team is new to estimation and story points feel intimidating

Process

1. Sort stories into buckets (XS through XXL) as a group
2. Review each bucket for consistency
3. Convert to story points later during refinement if needed

Affinity Estimation (Wall Estimation)

Best for estimating a large backlog quickly (30+ items in under an hour).

Process

1. Write each story on a card or sticky note
2. Draw a horizontal scale on a wall: Small <----> Large
3. Team members silently place cards on the wall relative to each other
4. Anyone can move any card, but must explain if challenged
5. Continue until the wall stabilizes (no more moves)
6. Draw vertical lines to group cards into point buckets
7. Record the estimates

When to use

• New project kickoff with a large initial backlog
• Quarterly planning where many epics need rough sizing
• Team has estimation fatigue from too many planning poker sessions

#NoEstimates Approach

An alternative philosophy that argues estimation itself is waste.

Core idea

Instead of estimating, break all work into roughly equal-sized stories (target: 1-2 days each). Then count stories instead of summing points.

How it works

• Every story must be small enough to complete in 1-2 days
• If a story is bigger, split it - don't estimate it, just split it
• Velocity = number of stories completed per sprint (not points)
• Forecasting uses throughput (stories/week) and Monte Carlo simulation

When #NoEstimates works well

• Mature teams with good story-splitting discipline
• Teams where estimation sessions consistently produce low-value debates
• Organizations that trust teams to self-manage without point-based tracking

When it does not work

• Teams that struggle to split stories consistently
• Organizations that need point-based roadmap commitments
• New teams that haven't yet calibrated what "small" means

Estimation anti-patterns

Kanban Flow - Advanced Practices

Kanban Principles

1. Start with what you do now - Kanban does not prescribe roles or ceremonies. Map your current workflow onto a board first, then improve.
2. Agree to pursue incremental change - No big-bang transformations. Small, continuous improvements.
3. Respect current roles and responsibilities - Kanban does not require Scrum roles. Existing titles and structures remain.
4. Encourage leadership at all levels - Anyone can suggest improvements to the flow.

Board Design

Standard columns

Backlog | Ready | In Progress | In Review | Testing | Done

Advanced column patterns

Split columns (doing/done):

In Progress    | Code Review      | QA
[Doing] [Done] | [Doing] [Done]   | [Doing] [Done]

Split columns make handoff points visible. An item sitting in "In Progress - Done" but not yet in "Code Review - Doing" reveals a queue. Queues are waste.

Expedite lane: Add a horizontal swim lane at the top for urgent items (production bugs, security fixes). Expedite items bypass WIP limits but should represent less than 10% of total throughput. If more than 10% of items are "expedited," nothing is actually expedited.

Class of service lanes:

WIP Limits

Setting initial WIP limits

Rule of thumb: WIP limit per column = number of people who work in that column.

For a team of 6 developers:

• In Progress: 6 (one per developer) or 4 (to encourage pairing)
• In Review: 3 (forces fast reviews)
• Testing: 2 (creates pull toward finishing)

What to do when WIP limit is hit

When a column is full:

1. First: Help finish something in a downstream column (pull from the right)
2. Second: Pair with someone on an in-progress item
3. Third: Work on technical debt or improvement items from the intangible lane
4. Never: Start a new item and exceed the WIP limit. The limit exists for a reason

Adjusting WIP limits

• If items queue between columns, lower the upstream WIP limit
• If a column is rarely full, its WIP limit may be too high
• If a column constantly blocks, the team may need more capacity there or the WIP limit is too low
• Adjust by 1 at a time. Wait 2-4 weeks before adjusting again

Flow Metrics

Cycle Time

Definition: The time from when work starts (enters "In Progress") to when it is done (enters "Done").

Cycle Time = Done Date - Start Date

Target: Cycle time should be stable and predictable. A high variance in cycle time means the team cannot make reliable delivery commitments.

Percentile-based targets:

• 50th percentile: "Half our items finish in X days or less"
• 85th percentile: "85% of our items finish in X days or less" (use for commitments)
• 95th percentile: "Nearly all items finish in X days or less"

Lead Time

Definition: The time from when a request is made (enters "Backlog") to when it is delivered (enters "Done").

Lead Time = Done Date - Request Date

Lead Time = Cycle Time + Queue Time. Reducing queue time (items waiting in "Ready" or between columns) is often more impactful than reducing active work time.

Throughput

Definition: The number of items completed per unit of time.

Throughput = Items completed / Time period

Track weekly throughput. Use the average over the last 4-6 weeks for forecasting.

Cumulative Flow Diagram (CFD)

The CFD shows the number of items in each state over time. Each column is a colored band. Key things to read from a CFD:

• Band width = WIP in that state. Wide bands mean items are accumulating
• Band slope = throughput. Flat bands mean no items are completing
• Parallel bands = stable flow. Diverging bands = bottleneck forming
• Vertical distance between bands = approximate cycle time

Forecasting with Kanban

Monte Carlo Simulation

Since Kanban does not use story points or velocity, forecasting uses historical throughput data:

1. Collect the last 8-12 weeks of throughput data (items completed per week)
2. Randomly sample from this data to simulate future weeks
3. Run 1000+ simulations
4. Report: "There is an 85% chance we will complete 20 items in the next 4 weeks"

Simple manual version:

• Best case: highest weekly throughput x weeks remaining
• Likely case: average weekly throughput x weeks remaining
• Worst case: lowest weekly throughput x weeks remaining

"How many" forecasting

Given a deadline, how many items can we deliver?

Items = Throughput per week x Weeks remaining

"When" forecasting

Given a number of items, when will they be done?

Weeks needed = Items remaining / Throughput per week

Scrumban - Combining Scrum and Kanban

When to use Scrumban

• Team wants Scrum ceremonies but Kanban flow
• Support/maintenance team with unpredictable work mixed with planned features
• Team transitioning from Scrum to Kanban (or vice versa)

How it works

• Keep sprint cadence for planning, review, and retro
• Replace sprint backlog commitment with WIP limits
• Use pull-based flow instead of push-based sprint planning
• Track both velocity (for sprint context) and cycle time (for flow)
• Replenish the "Ready" column when it drops below a threshold rather than loading an entire sprint during planning

Scrumban planning trigger

Instead of time-boxed planning, use a replenishment trigger: "When the Ready column drops below 5 items, schedule a planning session to refill it to 10 items."

Kanban for non-software teams

Kanban applies to any knowledge work. Common adaptations:

Marketing team board:

Ideas | Briefed | In Creation | In Review | Published | Measuring

HR/Recruiting board:

Open Roles | Sourcing | Screening | Interviewing | Offer | Onboarding

Personal Kanban (individual productivity):

To Do | Doing (WIP: 3) | Done

The key principle remains the same: visualize work, limit WIP, manage flow.

Sprint Ceremonies - Detailed Facilitation Guide

Sprint Planning

Pre-requisites

• Product Backlog is refined: top items have acceptance criteria, estimates, and are ordered by priority
• Team knows their average velocity (last 3-5 sprints)
• PO has a proposed sprint goal aligned with the product roadmap
• Any known PTO, holidays, or on-call duties are documented

Time-box guidelines

Facilitator checklist

1. Share the sprint goal before discussing individual stories
2. Let developers pull work - never assign stories to individuals during planning
3. If a story generates more than 5 minutes of debate, it needs more refinement - send it back to the backlog
4. Track capacity adjustments explicitly (PTO, on-call, training days)
5. End by reading back the sprint goal and committed items; get verbal confirmation

Capacity planning formula

Available capacity = (Number of devs) x (Sprint days) x (Focus factor)
Focus factor = 0.6 to 0.8 (accounts for meetings, support, interruptions)

Example: 5 devs, 10-day sprint, 0.7 focus factor
Available = 5 x 10 x 0.7 = 35 ideal dev-days

Map this to story points using historical data: if the team averages 40 points in a 10-day sprint with full attendance, and one dev is on PTO for 3 days, adjust to roughly 34 points (40 x 47/50 available dev-days).

Daily Standup (Daily Scrum)

Format

• Time-box: 15 minutes, same time every day
• Standing up is optional - the brevity is what matters
• Each person answers three questions or uses a walk-the-board approach

Three questions format:

1. What did I complete since last standup?
2. What will I work on today?
3. What is blocking me?

Walk-the-board format (recommended for mature teams):

• Start from the rightmost column (closest to Done)
• For each item in progress, the owner gives a brief status
• Focus on flow, not individual updates
• Naturally surfaces blockers and stale items

Anti-patterns to watch for

• Status report to the Scrum Master - The standup is for the team, not a report to management. Redirect: "Tell the team, not me."
• Problem-solving during standup - Note the issue, take it offline immediately after. Say: "Let's park that - who needs to be in the follow-up?"
• Going over 15 minutes - Strictly enforce. If consistently over time, the team has too many members (split into sub-teams) or too many blockers (systemic issue).
• Skipping when remote - Async standups via Slack/Teams are acceptable but must happen daily and be read by the whole team.

Sprint Review (Demo)

Purpose

Demonstrate the completed increment to stakeholders and gather feedback. This is NOT a status meeting - it is an inspection of the product.

Agenda template (1 hour for a 2-week sprint)

1. Sprint goal recap (5 min) - PO states the goal and whether it was met
2. Live demo (30 min) - Developers demo working software (not slides). Each completed story gets a brief walkthrough
3. Stakeholder feedback (15 min) - Structured Q&A. Capture feedback as new backlog items
4. Upcoming priorities (10 min) - PO shares what's coming next sprint and any priority shifts based on feedback

Tips

• Demo from the staging/production environment, not localhost
• Invite real stakeholders, not just the team - the point is external feedback
• Incomplete stories are not demoed. Partially done work is not an increment
• Record the demo for absent stakeholders

Sprint Retrospective

Safety check (run at the start)

Ask each team member to rate on a scale of 1-5 how safe they feel to share openly:

• 5: I'll talk about anything
• 4: I'll talk about most things
• 3: I'll talk about some things but hold back on others
• 2: I'll only say what's safe
• 1: I won't say anything meaningful

If the average is below 3, address psychological safety before running the retro. Consider running an anonymous format or having management leave the room.

Format rotation schedule

Rotate retrospective formats every 2-3 sprints to prevent staleness:

Action item quality checklist

Every action item must be:

• Specific - "Improve code reviews" is vague. "Add a review checklist to PR template by Friday" is specific.
• Owned - One person is accountable (not "the team")
• Time-bound - Due within the next sprint
• Achievable - Can actually be completed in one sprint
• Tracked - Added to the sprint backlog or a visible board

Tracking retro effectiveness

Keep a running log of retro actions and their completion rate:

Sprint 14 actions:
  [x] Add PR checklist template (owner: Alice, done Sprint 15)
  [x] Set up staging deploy pipeline (owner: Bob, done Sprint 15)
  [ ] Reduce flaky test count by 50% (owner: Carol, carried to Sprint 16)

Completion rate: 67% (target: >80%)

If completion rate drops below 50% for 3+ sprints, the team is committing to actions they cannot deliver. Reduce to 1-2 actions per retro.

Backlog Refinement (Grooming)

Cadence

• Allocate 10% of sprint capacity (roughly 1 hour per week for a 2-week sprint)
• Schedule mid-sprint to avoid conflicting with planning and review
• Attendance: PO + developers. Scrum Master facilitates.

What happens in refinement

1. PO presents upcoming backlog items (look 2-3 sprints ahead)
2. Team asks clarifying questions
3. Team writes or refines acceptance criteria together
4. Team estimates items (story points)
5. Large items are split into smaller stories
6. Items are re-ordered based on new understanding

Definition of Ready (entrance criteria for sprint planning)

An item is "Ready" for sprint planning when:

• User story follows the As a / I want / So that template
• Acceptance criteria are written in Given-When-Then format
• Story is estimated in story points
• Story is small enough to complete in one sprint (13 points or less)
• Dependencies are identified and resolved (or scheduled)
• UX designs are available (if applicable)
• Technical approach is discussed (not designed in detail, but understood)