8.2 Velocity, Capacity & Release Planning

8.2 Velocity, Capacity & Release Planning

Quick Answer: Velocity is a team-specific observation of work completed to the agreed Done rule in an iteration. Capacity Planning considers actual availability and known overhead without converting story points into hours. Burn-up Charts show Completed Work and Total Scope separately, making scope changes visible.

Predictable release planning in Agile depends on empirical metrics rather than optimistic commitments. By measuring actual historical throughput (Velocity) and calculating realistic availability (Capacity), Agile teams provide stakeholders with reliable forecasts for project completion dates and scope boundaries.

---

The Velocity Concept in Agile Delivery

Velocity is a team-specific observation of the amount of relatively sized work completed to the team's agreed Done rule in an iteration.

Golden Rules of Velocity

1. Strict Adherence to Definition of Done (DoD): Points are counted toward velocity only when an item meets the agreed Done rule. If an 8-point user story is 90% completed at the end of an iteration, the team earns 0 points for that story in that iteration. The story is re-evaluated, and points are awarded in the iteration where it fully meets the DoD.
2. Team-Specific Metric: Velocity is unique to a specific cross-functional team's baseline. Comparing Team A's velocity (45 points/sprint) to Team B's velocity (25 points/sprint) is invalid and dangerous. Team A may simply have a smaller story point unit baseline.
3. Empirical Stability: Velocity is unstable during early iterations (Forming and Storming stages). Repeated observations may produce a useful range, but no fixed number of iterations guarantees stability; team changes, work mix, and uncertainty can shift the result.

Historical vs. Estimated Initial Velocity

• Historical Velocity: Calculated using a rolling average of past completed iterations (e.g., completed points over the last 4 sprints: 30, 34, 28, 32 $\rightarrow$ Average Historical Velocity = 31 points per iteration).
• Estimated Initial Velocity (New Teams): When historical data is unavailable, avoid inventing precision. Plan a conservative amount from actual availability and item understanding, then replace assumptions with the team's own completed-work observations as soon as possible.

---

Capacity Planning and Focus Factor

While Velocity looks backward at past performance, Capacity Planning looks forward to determine how much work a team can realistically commit to in an upcoming iteration based on availability.

Calculating Net Productive Capacity

Capacity calculations must account for holidays, vacation time, corporate meetings, training, administrative duties, and production support interruptions.

$\text{Gross Capacity} = \text{Team Members} \times \text{Working Days in Iteration} \times \text{Daily Hours}$ $\text{Net Available Hours} = \text{Gross Capacity} - \text{Scheduled Time Off} - \text{Fixed Administrative Overhead}$ $\text{Productive Capacity} = \text{Net Available Hours} \times \text{Focus Factor}$

The Focus Factor

A Focus Factor is an optional, team-derived ratio between nominal availability and observed time available for planned work. There is no universal 60%-80% range. Derive any factor from the team's own history and revisit it when support load, meetings, or team composition changes.

Practical Calculation Example

• Team Size: 5 full-time developers
• Iteration Length: 10 working days (2 weeks)
• Gross Hours: $5 \times 10 \times 8 = 400 \text{ gross hours}$
• Planned Time Off: Developer A takes 2 days off (16 hours) $\rightarrow 400 - 16 = 384 \text{ available hours}$
• Fixed Meetings & Admin: 4 hours per developer for sprint planning, reviews, and retrospectives ($5 \times 4 = 20 \text{ hours}$) $\rightarrow 384 - 20 = 364 \text{ net available hours}$
• Focus Factor: 75% (0.75)
• Net Productive Capacity: $364 \text{ hours} \times 0.75 = 273 \text{ hours}$

Do not divide hours by story points: story points are relative and intentionally not a duration conversion. Instead, compare the upcoming effective capacity with a normal iteration. If this team usually completes about 31 points with 320 effective hours, a rough capacity adjustment is $31 \times (273/320) \approx 26$ points, followed by item-level discussion. The ratio is a planning aid, not a promise.

---

Release Planning & Visual Tracking Artifacts

Release Planning aligns product roadmaps, business priorities, and team velocity over whatever multi-iteration horizon supports the product decision. It answers two fundamental business questions:

1. Scope-Driven Release: "Given a fixed set of features, when will the release be ready?"
2. Date-Driven Release: "Given a fixed launch date, what feature scope can be delivered?"

$\text{Predicted Iterations to Release} = \frac{\text{Total Release Scope (Story Points)}}{\text{Average Historical Velocity (Points per Iteration)}}$

Burn-down vs. Burn-up Charts

Visual tracking artifacts allow teams and stakeholders to monitor progress toward release goals dynamically.

Burn-up Chart Visualization:
Points
 100 |============================== Total Scope Line (Scope Increase!)
  80 |............................/
  60 |.................../--------
  40 |........../--------
  20 | /--------                 Completed Work Line
   0 +---------------------------------- Iterations
       Sprint 1   Sprint 2   Sprint 3

On a Burn-up Chart, if stakeholders add 20 points of new scope during Sprint 2, the Total Scope Line steps upward from 80 to 100 points, while the Completed Work Line continues tracking team completion independently. This makes scope creep transparent to everyone.

---

Lead Time vs. Cycle Time Dynamics

Optimizing flow efficiency requires tracking how work items move through the delivery pipeline.

• Lead Time: The total elapsed time from the exact moment a customer or stakeholder submits a feature request until that feature is fully deployed and delivering value in production. Lead Time includes backlog queue time, refinement wait time, development, testing, and deployment.
• Cycle Time: The elapsed time from when the team actively begins work on a backlog item (moving it to "In Progress") until it meets the Definition of Done.

$\text{Lead Time} = \text{Queue / Wait Time} + \text{Cycle Time}$

Little's Law

Originating from operations research, Little's Law underpins Agile flow management:

$\text{Average Cycle Time} = \frac{\text{Average WIP (items)}}{\text{Average Throughput (items per unit time)}}$

Little's Law applies to a stable system over a consistent boundary and time period. Controlling WIP often improves flow and can reduce average cycle time, but the equation is a relationship among averages—not proof that changing a board limit alone guarantees a proportional result.

---

PMI-ACP Exam Strategy & Calculations

• Partial Credit Anti-Pattern: On exam questions, never assign partial point values for incomplete stories when calculating velocity. If 4 out of 5 stories are finished, calculate velocity based exclusively on the 4 finished stories.
• Ranges Over Single Dates: When predicting release completion dates, use velocity ranges (e.g., minimum velocity = 25, maximum velocity = 35) to provide stakeholders with optimistic and conservative completion target windows.