SkarpChapter 15 of 21
Agile Planning, Estimation, and Forecasting with Backlogs and Velocity
See how agile teams turn a dynamic product backlog into realistic forecasts, even when scope is still evolving and stakeholders keep refining their ideas.
From Ideas to Forecasts: How Agile Planning Really Works
Agile Planning Overview
In agile, planning is continuous: discover requirements, refine the product backlog, estimate relatively, and forecast using empirical data such as team velocity.
Why This Matters for CAPM
These skills live in the Agile Frameworks and Methodologies and Business Analysis Frameworks domains. You must show you can plan and forecast when scope evolves.
Key Ingredients
You will use: the product backlog, backlog refinement, user stories, relative estimation, team velocity, Definition of Done, acceptance criteria, and value-based prioritization.
What You Will Practice
We will practice turning vague ideas into backlog items, refining and estimating them, then using velocity and DoD to build realistic, honest forecasts.
Backlog Basics and Progressive Elaboration
Product Backlog Definition
For CAPM, remember: product backlog: "An ordered list of everything that is known to be needed in the product, managed by the product owner."
Adaptive Life Cycle Context
In an adaptive life cycle, detailed scope is defined and approved just before each iteration, not all up front, so the backlog must stay flexible.
Progressive Elaboration
Progressive elaboration means starting with coarse epics, then refining, clarifying, and splitting items as implementation time approaches.
Exam Trap: Refinement vs Planning
Backlog refinement is ongoing discovery and clarification. Sprint planning is the event where the team selects and commits work for the next sprint.
Iterative Requirements Discovery in Action
The Vague Idea
Campus app example: initial backlog item is "Students can discover relevant events"—too vague to plan around.
Round 1: User Story
Refinement clarifies outcome: As a student, I want to see upcoming events that match my interests so that I do not miss activities I care about.
Round 2: Split the Work
The team splits into smaller slices: filter by category, filter by date, save favorite categories—each becomes its own backlog item.
Round 3: Acceptance Criteria
They add clear acceptance criteria, e.g., selecting “music” shows only music events, ensuring each story is small, clear, and testable.
User Stories, Value Clauses, and Acceptance Criteria
User Story Structure
User stories: As a [role], I want [capability] so that [value]. The "so that" value clause clarifies why the feature matters.
Value Clause for Prioritization
The value clause links each story to outcomes, supporting prioritization by business value instead of technical convenience.
Stakeholder Focus
A stakeholder is "An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by" the project.
Acceptance Criteria Role
Acceptance criteria are "A set of conditions that is required to be met before deliverables are accepted" and make each story testable.
Relative Estimation: Story Points and Sizing
Why Relative Estimation
Agile teams estimate work relatively (story points, sizes) instead of hours early on, focusing on size rather than calendar time.
How It Works
Pick a reference story, give it a size, then size new stories by asking if they are smaller, similar, or larger than the reference.
Example Sizing
If "filter by category" is 3 points, "filter by date" might also be 3, while "personalized recommendations" might be 8 points.
Exam Trap: Team-Specific
Story points are team-specific; you cannot compare point-based velocity between different teams on the exam or in practice.
Team Velocity and Empirical Forecasting
What Is Velocity
Velocity is the amount of work a team completes in an iteration, usually in story points, based only on work that meets the Definition of Done.
Simple Velocity Example
If a team completes 18, 22, and 20 points in three sprints, average velocity is (18+22+20)/3 = 20 points per sprint.
Using Velocity to Forecast
With 120 points remaining and a 20-point velocity, you forecast about 6 sprints. More scope means more sprints; less scope means fewer.
Empirical Process Control
Agile uses transparency, inspection, and adaptation: show backlog and velocity, inspect results each sprint, and adapt forecasts and priorities.
Definition of Done and Planning Constraints
Definition of Done
The Definition of Done (DoD) is the team’s shared checklist of what must be true for any backlog item to be considered truly complete.
DoD vs Acceptance Criteria
DoD is global for all work; acceptance criteria are specific to an individual story or backlog item.
Planning Impact
A stricter DoD means each item takes more effort, so fewer items fit in a sprint and velocity may be lower but quality is higher.
Exam Trap: Partially Done
Code that is not tested or integrated does not meet DoD and must not be counted toward velocity or release forecasts.
Prioritization by Business Value vs Technical Convenience
Value-Based Prioritization
Agile teams order the backlog mainly by business value and outcomes: impact on users, goals, risk reduction, and learning.
Example Ordering
Deliver login and basic event list first, then search and filters, then personalization, and only later cosmetic UI features.
Technical Convenience Pitfall
Ordering by technical convenience or individual utilization can delay user-visible value and reduce feedback.
Exam Heuristic
On CAPM, choose options that emphasize value, risk reduction, and learning over keeping specialists 100% busy.
Thought Exercise: Refining and Prioritizing a Messy Backlog
Work through this scenario mentally (or jot notes) to practice backlog refinement, prioritization, and forecasting.
Scenario:
You join a small agile team building a study‑planner app. The initial backlog from stakeholders is:
- “Add AI”
- “Better calendar”
- “Sync with everything”
- “Cool dashboard”
- “Share with friends”
Activity 1 – Rewrite as user stories:
- Pick any two items and rewrite them as user stories with value clauses. Example pattern: As a [role], I want [capability] so that [value].
- Add at least one acceptance criterion for each.
Activity 2 – Split and refine:
- Identify which item is clearly too big or vague to estimate.
- Break it into at least two smaller, clearer backlog items.
Activity 3 – Prioritize by value:
- For your refined items, rank them 1–3 by value to students (who are the main users).
- Consider: Which feature would let a student get meaningful benefit this week?
Activity 4 – Rough estimation:
- Assume your team’s reference story (3 points) is “View weekly calendar of tasks.”
- For your top 3 items, assign 2, 3, 5, or 8 points relative to that reference.
Reflect:
- Which items rose to the top when you focused on outcomes, not “coolness” or tech?
- Which acceptance criteria helped you spot hidden complexity that affects estimates?
This is the same reasoning you will need to apply quickly on exam scenarios: clarify, split, value‑rank, then estimate and plan.
Quick Check: Backlog Refinement and Estimation
Answer this CAPM‑style question to check your understanding.
During a backlog refinement session, the team finds that the top-priority item is very vague but urgently requested by stakeholders. What is the BEST agile response?
- Estimate it quickly in hours so it can be committed to the next sprint as requested.
- Ask the Product Owner to remove it from the backlog until a full requirements document is written.
- Collaborate with the Product Owner and stakeholders to clarify, split, and add acceptance criteria before committing it to a sprint.
- Move it to the bottom of the backlog and focus on technically easy items at the top.
Show Answer
Answer: C) Collaborate with the Product Owner and stakeholders to clarify, split, and add acceptance criteria before committing it to a sprint.
Agile teams use iterative requirements discovery and backlog refinement to clarify high-priority items before commitment. Option C reflects this: collaborate to clarify, split, and define acceptance criteria so the work becomes small, clear, and estimable. Estimating vague work in hours (A) is risky, removing it entirely (B) ignores urgency, and pushing it down in favor of technically easy items (D) violates value-based prioritization.
Quick Check: Velocity and Forecasting
Test your ability to use velocity in a simple forecast.
A Scrum team has completed 18, 20, and 22 story points in their last three sprints. The Product Owner wants to know roughly how many more 2-week sprints are needed to complete a 120-point release backlog, assuming similar conditions. What is the MOST reasonable forecast?
- About 4 sprints, because the team should improve over time.
- About 6 sprints, based on the team’s observed average velocity.
- About 3 sprints, if the team works overtime.
- It is impossible to forecast in agile because requirements may change.
Show Answer
Answer: B) About 6 sprints, based on the team’s observed average velocity.
Average velocity is (18 + 20 + 22) / 3 = 20 points per sprint. With 120 points remaining, a reasonable empirical forecast is about 120 / 20 = 6 sprints. Agile does allow forecasting, but based on observed data and with the understanding that scope can change. Options A and C ignore empirical data; D is incorrect because agile uses empirical forecasting.
Key Terms Review
Flip through these cards to reinforce critical CAPM terms from this module.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- adaptive life cycle
- A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
- acceptance criteria
- A set of conditions that is required to be met before deliverables are accepted.
- stakeholder
- An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
- velocity (agile context)
- The amount of work a team completes in an iteration, typically measured in story points, based only on items that meet the Definition of Done.
- Definition of Done (DoD)
- A shared understanding of what it means for work to be completely finished and potentially releasable, usually expressed as a checklist that applies to all backlog items.
- user story value clause
- The "so that" part of a user story, explaining the outcome or benefit, which supports prioritization by business value and outcomes.
- progressive elaboration
- The iterative process of increasing the level of detail in a plan or requirement as greater information and more accurate estimates become available.
Pulling It Together: From Backlog to Realistic Forecasts
End-to-End Agile Planning
Flow: capture ideas in the product backlog, refine as user stories, estimate relatively, track velocity, and forecast iterations empirically.
Key Exam Moves
For vague but urgent items, refine before commitment. For date questions, use velocity-based forecasts and explain scope impacts.
Done and Forecasts
Only work that meets the Definition of Done and acceptance criteria counts toward velocity and release forecasts.
Your Next Step
Use the next Skarp mock exam and diagnostic to see how well you can apply these ideas under time and get targeted review.
Key Terms
- velocity
- The amount of work a team completes in an iteration, typically measured in story points, based only on items that meet the Definition of Done.
- user story
- A short, simple description of a feature told from the perspective of the user or customer, often following the format: As a [role], I want [capability] so that [value].
- stakeholder
- An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- Definition of Done
- A shared understanding of what it means for work to be completely finished and potentially releasable, usually expressed as a checklist that applies to all backlog items.
- acceptance criteria
- A set of conditions that is required to be met before deliverables are accepted.
- adaptive life cycle
- A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
- progressive elaboration
- The iterative process of increasing the level of detail in a plan or requirement as greater information and more accurate estimates become available.