Determining Velocity in Adaptive Project Management
PMBOK v8 Definition
Determining velocity is the process of measuring the rate at which deliverables are produced, validated, and accepted within a given time per iteration (agreed-upon work cycle duration, typically 2 weeks or 1 month). This concept belongs to the Schedule Management Knowledge Area and is performed during the Executing Process Group within adaptive (agile) project environments.
Why It Matters for the Exam
Velocity appears frequently on the PMI exam in questions about adaptive project scheduling, iteration planning, and team performance measurement. You will encounter it in situational questions where the project manager needs to forecast completion dates, reprioritize backlog items, or assess whether the team is delivering at a sustainable pace.
Key Points to Remember (for the exam)
- Definition: Velocity = rate at which deliverables are produced, validated, AND accepted per iteration
- Typical iteration duration: 2 weeks or 1 month (agreed-upon work cycle)
- Primary purpose: Forecasting future delivery capacity and informing backlog reprioritization
- Key Output: Work performance information used for schedule forecasts
- Common Confusion: Velocity measures accepted deliverables, not just completed work – validation and acceptance are required
- Related Activity: Retrospectives are conducted alongside velocity tracking to correct and improve processes
- When velocity changes: Indicates the project schedule has changed, triggering change management
Typical PMI Exam Example
A project team completes 8 user stories in a 2-week iteration. After validation, only 6 stories are accepted by the product owner. The team's velocity is 6 stories per iteration, not 8. This velocity is then used to forecast how many iterations are needed to complete the remaining 30 backlog items (approximately 5 iterations).
PMI Exam Traps
-
Trap: Confusing velocity with team productivity
-
Reality: Velocity measures accepted deliverables, not effort expended or tasks completed
-
Trap: Using velocity from the first iteration as a fixed benchmark
-
Reality: Velocity stabilizes over multiple iterations; early iterations may show lower velocity as the team matures
-
Trap: Treating velocity as a target to increase
-
Reality: Velocity is a measurement tool for forecasting, not a performance goal – increasing velocity artificially leads to poor quality
-
Trap: Confusing velocity with throughput or cycle time
-
Reality: Velocity is iteration-based (deliverables per fixed timebox), while throughput measures items per unit time and cycle time measures time per item
Important PMI Connections
| Related Concept | Relationship Type | Exam Attention Point |
|---|---|---|
| Backlog Refinement | Complementary | Velocity informs reprioritization of remaining work plan |
| Schedule Forecasts | Output of | Velocity data produces schedule forecasts for future iterations |
| Retrospectives | Parallel Activity | Velocity is reviewed in retrospectives to identify process improvements |
| Change Requests | Trigger | When velocity changes significantly, the project schedule has changed |
| Sprint Reviews | Verification | Deliverables counted in velocity must be reviewed and accepted |
Quick Review Questions
-
What three activities must occur for a deliverable to count toward velocity?
-
If a team's velocity is 5 story points per 2-week iteration and 40 story points remain, how many iterations are forecasted?
-
What is the difference between a deliverable being "completed" and a deliverable being "accepted" in velocity measurement?
-
When velocity decreases unexpectedly, what two actions should the project manager take according to PMBOK v8?
-
Why should velocity not be used as a team performance target?
PMBOK v8 Reference
Section 2.2.1.8 – Determining Velocity (Schedule Management Knowledge Area, Executing Process Group, Adaptive Approaches)