TECH **Agile & Scrum: Velocity, Burndown/Burn-up Charts, and Forecasting – Zero-Fluff Study Guide**

Agile & Scrum: Velocity, Burndown/Burn-up Charts, and Forecasting – Zero-Fluff Study Guide

1. What This Is & Why It Matters

You’re a Scrum Master or Agile coach on a team that just inherited a chaotic backlog. The product owner (PO) keeps asking, "When will this epic be done?" but the team’s estimates are all over the place. Stakeholders are frustrated, sprints are failing, and morale is dropping.

This guide is your survival kit.

• Velocity tells you how much work your team actually completes in a sprint (not what they hope to).
• Burndown/Burn-up charts give you a real-time visual of progress (or lack thereof).
• Forecasting lets you answer "When will we ship?" with data, not guesses.

Why this matters in production:
- Without velocity, you’re flying blind—estimates are wishful thinking.
- Without burndowns, you won’t spot blockers until it’s too late.
- Without forecasting, stakeholders will either micromanage or lose trust in your team.

Real-world scenario:
You’re leading a team migrating a monolith to microservices. The CTO wants a timeline. If you say "6 months" without data, you’ll either underpromise (and look slow) or overpromise (and fail). If you use velocity and forecasting, you can say: "Based on our last 3 sprints, we average 25 story points per sprint. The epic is 150 points. At this rate, we’ll finish in 6 sprints—give or take a sprint for risks."

2. Core Concepts & Components

? Velocity

• Definition: The average number of story points (or other units) a team completes in a sprint.
• Production insight: Velocity is not a measure of productivity—it’s a planning tool. If you use it to compare teams, you’ll incentivize gaming the system (e.g., inflating estimates).
• Key rule: Only count done work (Definition of Done must be strict).

? Story Points

• Definition: A relative unit of effort (not hours). 1 point = "trivial," 5 = "moderate," 13 = "complex."
• Production insight: If your team argues over points, they’re missing the point. Points are relative—a 5-point story should feel twice as hard as a 2-point one.
• Trap: Never equate points to hours. A 5-point story might take 2 hours for a senior dev but 2 days for a junior.

? Burndown Chart

• Definition: A graph showing remaining work (y-axis) over time (x-axis) in a sprint.
• Production insight: A flat line = blocked work. A steep drop = either great progress or underestimated stories.
• Example:
  Day 1: 50 points remaining Day 5: 20 points remaining Day 10: 0 points remaining (ideal)

? Burn-up Chart

• Definition: A graph showing completed work (y-axis) over time (x-axis), with a line for total scope.
• Production insight: Unlike burndowns, burn-ups show scope changes (e.g., "We added 10 points mid-sprint").
• Example:
  Day 1: 0/50 points done Day 5: 30/50 points done Day 10: 50/60 points done (scope increased)

? Forecasting (Monte Carlo Simulation)

• Definition: Using historical velocity to predict future completion dates.
• Production insight: Forecasting isn’t a guarantee—it’s a probability. Always give ranges (e.g., "80% chance we’ll finish in 5-7 sprints").
• Tool: Use ActionableAgile or Excel for simulations.

? Definition of Done (DoD)

• Definition: A checklist of criteria a story must meet to be "done" (e.g., "Code reviewed," "Tested," "Deployed to staging").
• Production insight: If DoD is vague, velocity becomes meaningless. Example: If "done" = "code written," but not tested, your velocity is a lie.

? Sprint Goal

• Definition: A single objective for the sprint (e.g., "Enable user login via OAuth").
• Production insight: Without a sprint goal, the team lacks focus. If 80% of stories are done but the goal isn’t met, the sprint failed.

3. Step-by-Step: Hands-On Forecasting

Prerequisites

• A Scrum team with at least 3 sprints of historical velocity data.
• A backlog with estimated stories (story points or t-shirt sizes).
• A tool (Jira, Excel, or ActionableAgile).

Step 1: Calculate Historical Velocity

1. Open your sprint history (e.g., Jira → Reports → Velocity Chart).
2. Record the completed story points for each sprint:
   Sprint 1: 20
Sprint 2: 25
Sprint 3: 18
Sprint 4: 30
3. Calculate the average:
   (20 + 25 + 18 + 30) / 4 = 23.25 → Round to 23
   Why? This is your baseline velocity.

Step 2: Estimate the Backlog

1. Sum the story points for the epic/feature you’re forecasting:
   ```
   Epic: "User Profile Page"
2. Story 1: 5
3. Story 2: 8
4. Story 3: 13
5. Story 4: 3
   Total: 29 points
   ```
6. If using t-shirt sizes (S/M/L/XL), convert to points (e.g., S=2, M=5, L=8, XL=13).

Step 3: Forecast Completion

1. Divide the total backlog by velocity:
   29 points / 23 points per sprint ≈ 1.26 sprints
2. Add buffer: Multiply by 1.5x for risks:
   1.26 * 1.5 ≈ 2 sprints
3. Give a range: Use the lowest and highest historical velocities:
   Best case (30 pts/sprint): 29/30 ≈ 1 sprint
Worst case (18 pts/sprint): 29/18 ≈ 2 sprints
→ "We’ll finish in 1-2 sprints."

Step 4: Create a Burn-up Chart (Excel Example)

1. Open Excel and create a table:
   | Sprint | Completed | Total Scope |
   |--------|-----------|-------------|
   | 1 | 20 | 100 |
   | 2 | 45 | 100 |
   | 3 | 60 | 120 | (scope increased)
2. Insert a line chart with:
3. X-axis: Sprint
4. Y-axis: Points
5. Two lines: "Completed" and "Total Scope"
6. Interpretation:
7. If "Completed" line flattens, the team is blocked.
8. If "Total Scope" line rises, scope is creeping.

4. ? Production-Ready Best Practices

? Security (Team Dynamics)

• Never use velocity for performance reviews. If devs know points = bonuses, they’ll inflate estimates.
• Protect the Definition of Done. If "done" = "code written," velocity is meaningless.

? Cost Optimization (Planning)

• Use velocity to right-size sprints. If velocity is 20 but you plan 30, you’re setting up failure.
• Forecast before committing to deadlines. If the PO demands a feature in 2 sprints but the forecast says 4, negotiate scope.

?️ Reliability & Maintainability

• Track velocity trends, not single sprints. A dip in one sprint isn’t a crisis—three dips in a row is.
• Update forecasts when scope changes. If the PO adds 20 points mid-epic, recalculate.

?️ Observability (Metrics to Monitor)

• Burndown slope: If it’s flat for 3 days, investigate blockers.
• Scope change rate: If "Total Scope" keeps rising, the PO is adding too much mid-sprint.
• Velocity stability: If velocity swings >20% between sprints, estimates are inconsistent.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "What does a flat burndown chart indicate?"
2. ❌ "The team is lazy."

3. ✅ "Work is blocked or underestimated."

4. "How do you calculate velocity?"

5. ❌ "Sum all story points in the sprint."

6. ✅ "Average completed story points over the last 3-5 sprints."

7. "When should you update a forecast?"

8. ❌ "Never—it’s set in stone."
9. ✅ "When scope changes or velocity trends shift."

Key Trap Distinctions

• Burndown vs. Burn-up:
• Burndown = remaining work.
• Burn-up = completed work + scope changes.
• Velocity vs. Capacity:
• Velocity = historical output.
• Capacity = available time (e.g., "We have 4 devs × 6 hours/day").

Scenario-Based Question

"Your team’s velocity is 25 points/sprint. The epic is 100 points. The PO wants it in 3 sprints. What do you do?" - ❌ "Say yes and hope for the best." - ✅ "Negotiate scope: 'We can deliver 75 points in 3 sprints. Which 25 can wait?'"

7. ? Hands-On Challenge

Challenge:
Your team’s last 5 sprints: [20, 25, 18, 30, 22] points.
An epic is 120 points.
1. What’s the average velocity? 2. What’s the forecasted number of sprints (with buffer)? 3. If the PO adds 30 points mid-epic, what’s the new forecast?

Solution:
1. Average velocity = (20+25+18+30+22)/5 = 23 2. Forecast = 120/23 ≈ 5.2 → 6 sprints (with 1.5x buffer: 5.2*1.5 ≈ 8 sprints) 3. New forecast = (120+30)/23 ≈ 6.5 → 7-8 sprints

Why it works:
- Uses historical data, not guesses.
- Adds buffer for risks.
- Adjusts for scope changes.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. ActionableAgile – Free tools for forecasting.
2. Scrum.org’s Evidence-Based Management Guide – How to use metrics responsibly.
3. Mountain Goat Software – Velocity – Mike Cohn’s deep dive.
4. Jira Velocity Chart Tutorial – How to generate reports in Jira.