Understanding Story Points
Story points are a unit of measure used to estimate the relative effort required to complete a user story. Unlike time-based estimates (hours/days), story points consider:
Key Factors:
- Complexity - How difficult is the work?
- Amount of Work - How much code/testing is needed?
- Risk/Uncertainty - How many unknowns exist?
Common Story Point Scale (Fibonacci):
- 1 point = Very simple task (30 minutes - 2 hours)
- 2 points = Simple task (2-4 hours)
- 3 points = Medium task (4-8 hours)
- 5 points = Large task (1-2 days)
- 8 points = Very large task (2-3 days)
- 13 points = Epic (should be broken down)
Practical Exercise: Building a Task Management App
Team: 4 developers (Frontend, Backend, QA, DevOps)
Sprint Duration: 2 weeks (10 working days)
Team Velocity: 45 story points (based on last 3 sprints)
User Stories with Story Point Estimates
| Story ID | User Story | Story Points | Justification |
|---|
| TM-101 | As a user, I want to create a new task | 3 | Simple CRUD operation |
| TM-102 | As a user, I want to edit task details | 2 | Modify existing functionality |
| TM-103 | As a user, I want to delete tasks | 1 | Simple delete operation |
| TM-104 | As a user, I want to mark tasks as complete | 2 | Status update with UI changes |
| TM-105 | As a user, I want to filter tasks by status | 5 | Complex filtering logic |
| TM-106 | As a user, I want to search tasks by keyword | 8 | Search algorithm + indexing |
| TM-107 | As a user, I want to set task priorities | 3 | Add priority field + sorting |
| TM-108 | As a user, I want to assign due dates | 5 | Date picker + validation |
| TM-109 | As a user, I want to receive notifications | 13 | Push notifications system |
| TM-110 | As a QA, I want comprehensive test coverage | 8 | Unit + integration tests |
Total Available: 50 story points
Team Capacity: 45 story points
Decision: Remove TM-109 (13 pts) as it’s too large. Total committed: 37 points
Sprint Execution Simulation
Day-by-Day Progress
| Day | Stories Completed | Points Completed | Cumulative Remaining | Ideal Remaining | Status |
|---|
| 0 | Sprint Start | 0 | 37 | 37 | ✅ On track |
| 1 | TM-103 (Delete) | 1 | 36 | 33.3 | ⚠️ Slightly behind |
| 2 | TM-102 (Edit) | 2 | 34 | 29.6 | ⚠️ Behind schedule |
| 3 | TM-101 (Create), TM-104 (Complete) | 5 | 29 | 25.9 | ✅ Caught up |
| 4 | TM-107 (Priority) | 3 | 26 | 22.2 | ✅ On track |
| 5 | Weekend | 0 | 26 | 18.5 | - |
| 6 | Weekend | 0 | 26 | 14.8 | - |
| 7 | TM-105 (Filter) | 5 | 21 | 11.1 | ❌ Behind |
| 8 | TM-108 (Due dates) | 5 | 16 | 7.4 | ✅ Excellent recovery |
| 9 | TM-106 (Search) - 50% done | 4 | 12 | 3.7 | ❌ Risk! |
| 10 | TM-106 (Search) completed, TM-110 (Testing) | 12 | 0 | 0 | ✅ Success! |
Sprint Analysis
1. Velocity Calculation
- Points Planned: 37
- Points Completed: 37
- Success Rate: 100%
- Previous Velocity: Average of last 3 sprints (42, 45, 48) = 45 points
- New Team Velocity: (42 + 45 + 48 + 37) ÷ 4 = 43 points
2. Burndown Chart Insights
- Day 1-2: Team started slowly (learning curve, environment setup)
- Day 3-4: Strong recovery, good collaboration
- Day 7: Weekend disrupted momentum
- Day 9: Search story was underestimated (should have been 13 points)
- Day 10: Team worked overtime to meet commitment
3. Lessons Learned
- Estimation: Complex search functionality was underestimated
- Planning: Should break down 8+ point stories further
- Risk Management: Earlier identification of Day 9 risks needed
- Team Dynamics: Strong collaboration when under pressure
Visual Example of Burndown Chart
xychart-beta
title "Sprint Burndown Chart - Task Management App Sprint"
x-axis [Day0, Day1, Day2, Day3, Day4, Day5, Day6, Day7, Day8, Day9, Day10]
y-axis "Remaining Story Points" 0 --> 40
line [37, 36, 34, 29, 26, 26, 26, 21, 16, 12, 0]
line [37, 33.3, 29.6, 25.9, 22.2, 18.5, 14.8, 11.1, 7.4, 3.7, 0]
Legend:
- Blue Line (Actual Progress): Shows real team progress day by day
- Orange Line (Ideal Progress): Shows perfect linear burndown
- Analysis: Team caught up after slow Day 2, finished strong with only 3 points remaining
Your Turn: Create Next Sprint
Given Information:
- New Team Velocity: 43 points
- Available Stories:
- User authentication (8 pts)
- Password reset (5 pts)
- User profiles (13 pts - needs breakdown)
- Email notifications (8 pts)
- Data export (5 pts)
- UI dark mode (3 pts)
- Performance optimization (8 pts)
- Mobile responsive design (13 pts - needs breakdown)
Your Tasks:
- Which stories would you commit to for the next sprint?
- Which large stories need to be broken down?
- Create a day-by-day plan with realistic burndown expectations
- Identify potential risks and mitigation strategies
Recommended Approach:
- Start with high-priority, well-understood stories
- Break down 13-point stories into smaller chunks
- Leave some buffer for unexpected issues
- Plan for testing and code review time
FAQs
Key Elements of a Burndown Chart:
- X-Axis (Horizontal): Time (usually days in the sprint)
- Y-Axis (Vertical): Remaining work (story points or hours)
- Ideal Line: Straight diagonal line from start to zero
- Actual Line: Shows real progress day by day
Chart Interpretation:
- Line above ideal: Team is behind schedule
- Line below ideal: Team is ahead of schedule
- Flat line: No progress made (stories in progress)
- Steep drop: Multiple stories completed
Healthy Burndown Patterns:
- Consistent downward trend
- Minor fluctuations around the ideal line
- Reaches zero by sprint end
Problems with Time Estimates:
- Different skill levels = different time requirements
- Interruptions and meetings affect actual hours
- Pressure to meet time commitments leads to poor quality
Advantages of Story Points:
- Relative Sizing: Compare stories to each other, not absolute time
- Team Velocity: Track how many points the team completes per sprint
- Improved Planning: Use historical velocity for future sprint planning
- Less Pressure: Focus on delivering value, not meeting time targets
Example Velocity Calculation:
- Sprint 1: 35 points completed
- Sprint 2: 42 points completed
- Sprint 3: 38 points completed
- Average Velocity: 38 points per sprint
- Next Sprint Planning: Commit to ~38 points
Planning Poker Process:
- Present the User Story - Product Owner explains the requirements
- Discuss and Ask Questions - Team clarifies any uncertainties
- Individual Estimation - Each team member selects a card privately
- Reveal Simultaneously - All cards shown at once
- Discuss Differences - Focus on highest and lowest estimates
- Re-estimate - Repeat until consensus is reached
Common Estimation Cards (Fibonacci):
- 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ?
Why Fibonacci Scale Works:
- Forces relative thinking rather than precise estimation
- Larger numbers have bigger gaps, reflecting increased uncertainty
- Prevents false precision in complex tasks
Do’s:
- Use the whole team for estimation (diverse perspectives)
- Base estimates on relative complexity, not time
- Keep a reference story as a baseline (e.g., “This is similar to login, which was 3 points”)
- Re-estimate if requirements change significantly
- Track and learn from estimation accuracy over time
Don’ts:
- Don’t convert story points to hours/days
- Don’t let one person dominate the estimation
- Don’t estimate stories that are too large (break them down first)
- Don’t change estimates mid-sprint unless scope changes
- Don’t use story points for individual performance measurement
Complete Agile Process Flow
flowchart TD
A[Product Backlog] --> B[Sprint Planning]
B --> C[Sprint Backlog with Story Points]
C --> D[Daily Sprint Work]
D --> E[Update Burndown Chart Daily]
E --> F{Sprint End?}
F -->|No| D
F -->|Yes| G[Sprint Review]
G --> H[Sprint Retrospective]
H --> I[Update Team Velocity]
I --> A
%% Styling
style C fill:#e1f5fe
style E fill:#fff3e0
style I fill:#f3e5f5
%% Additional details
C1[Story Points:<br/>• Estimate relative effort<br/>• Use Fibonacci scale<br/>• Team consensus via Planning Poker]
E1[Burndown Chart:<br/>• Track remaining work daily<br/>• Compare actual vs ideal progress<br/>• Identify sprint risks early]
I1[Team Velocity:<br/>• Average story points per sprint<br/>• Used for future planning<br/>• Improves over time]
C -.-> C1
E -.-> E1
I -.-> I1
This diagram shows how story points and burndown charts integrate into the complete Agile/Scrum process.