SkarpChapter 18 of 20
Agile Requirements: Product Backlog, Roadmaps, and Validation
See how agile teams manage evolving requirements through product backlogs and roadmaps, and how they validate that what was built truly meets stakeholder needs.
From Predictive Requirements to Agile Requirements
Bridging Predictive and Agile
Earlier modules focused on eliciting, analyzing, and tracing requirements mostly in predictive contexts. Now you will see how those same skills apply when teams use agile or other adaptive life cycles.
Adaptive Life Cycle Reminder
An adaptive life cycle is "A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration." Scope evolves over time.
Living Requirements
In adaptive projects, detailed scope is not frozen. Requirements live in a product backlog and are organized over time using product roadmaps and releases instead of a single upfront baseline.
BA Skills in Agile
You still use a requirements traceability matrix, acceptance criteria, solution evaluation, and gap analysis, but you apply them incrementally as each product increment is planned, built, and validated.
CAPM Expectations
For CAPM, you must explain backlogs and roadmaps, connect traceability to agile items and tests, judge readiness for delivery, and compare validation in predictive versus adaptive approaches.
Canonical Definition and Structure of the Product Backlog
Canonical Definition
A product backlog is "An ordered list of everything that is known to be needed in the product, managed by the product owner." Remember this exact wording for the exam.
Ordered, Not Just Listed
Ordered means every item has a clear place in the sequence. The team can always see what comes next; two items cannot both be "top priority" at the same time.
Everything Needed
The backlog holds all work that contributes to the product: features, enhancements, bug fixes, technical tasks, and research spikes, not just user stories.
Managed by the Product Owner
Many stakeholders propose items, but the product owner is accountable for what is in the backlog and how it is ordered, based on value, risk, and strategy.
Typical Backlog Fields
Each item usually has an ID, title, description or user story, acceptance criteria, estimate, priority, and links to source requirements, regulations, and test cases.
Backlog Refinement Example with Business Analysis Focus
Raw Request
Stakeholder says: "Make login more secure." This is vague and not testable. Your BA role is to refine this into clear, testable backlog items.
Clarify and Analyze
You ask questions about threats and regulations, then perform a quick gap analysis: current simple login versus future state with multi-factor authentication for risky actions.
Create User Stories
You split the vague request into specific user stories, such as MFA when logging in from a new device and extra confirmation for high-value transfers.
Add Acceptance Criteria
For each story, you define acceptance criteria like code expiry time, lockout after failed attempts, and logging for audit. These guide development and testing.
Link to Traceability Matrix
You link each story to a higher-level requirement in the requirements traceability matrix, such as a security regulation requirement ID. Now items are traceable end to end.
Product Roadmaps and Releases in Agile Projects
What is a Product Roadmap?
A product roadmap is a visual, time-oriented view of how major features and outcomes will be delivered to meet strategy. It connects the vision to the detailed product backlog.
Agile Roadmap Traits
Agile roadmaps are outcome-focused, organized by time horizons (near, mid, long term), and flexible. They are updated as you learn from each release and its metrics.
Releases in Agile
A release is a deployable package of functionality that delivers value. A roadmap shows releases along a timeline, plus the themes or epics planned for each.
Roadmap vs Backlog
The roadmap answers "why and when" at a high level, while the backlog answers "what exactly" to build. Epics on the roadmap are decomposed into backlog items over time.
Exam-Relevant Distinction
On CAPM, remember: an agile roadmap is not a rigid Gantt chart. It is a communication and alignment tool that supports adaptation as priorities and learning evolve.
Roadmap-to-Backlog Example with Releases and Metrics
Vision to Roadmap
A learning platform has the vision "personalized, mobile-first learning." The team builds a one-year roadmap with quarterly releases aligned to that vision.
Example Releases
Q3: onboarding and catalog. Q4: personalized recommendations. Q1 next year: mobile app launch. Each release has clear outcome statements and target metrics.
From Roadmap to Epics
Roadmap themes become epics, such as "User Registration" or "Recommendation Engine." These epics then decompose into detailed backlog items as their release nears.
BA Contributions
You ensure epics trace to business objectives, define acceptance criteria and nonfunctional requirements, and propose solution evaluation metrics for each release.
Exam Connection
On CAPM, be ready to trace the chain: strategy → roadmap outcomes → epics → backlog items → acceptance criteria and performance metrics.
Requirements Traceability Matrix in Adaptive Projects
Canonical RTM Definition
A requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them." This applies in both predictive and adaptive projects.
Adaptive RTM Links
In agile, the matrix links business objectives, regulations, epics, backlog items, design elements, and test cases. It evolves as the product backlog changes.
Impact Analysis
When requirements change, the matrix helps you see which backlog items, designs, and tests are affected. This supports informed decisions and risk management.
Compliance Evidence
Regulated industries still require traceability. Even agile teams maintain lightweight matrices, often tied to backlog IDs, to show that every requirement is satisfied.
Exam Trap
Do not assume agile means "no traceability." The backlog does not replace the matrix; they work together to manage evolving requirements responsibly.
Validating Requirements and Readiness for Delivery in Agile
Acceptance Criteria Reminder
Acceptance criteria are "A set of conditions that is required to be met before deliverables are accepted." In agile, each backlog item should have clear, testable criteria.
Good Criteria Traits
Criteria should be specific, measurable, and testable. They often include nonfunctional aspects like performance, security, or usability, not just functional behavior.
Iteration-Level Validation
At iteration reviews, stakeholders see working software. The product owner accepts or rejects items based on acceptance criteria and test results, not gut feel.
Traceability and Metrics
You update the traceability matrix to mark satisfied requirements and compare pre- and post-release metrics to evaluate business value delivered by the increment.
Beyond Passing Tests
Readiness also depends on compliance, coverage of key user segments, and operational readiness. A feature can "pass tests" yet still be unready for real-world use.
Thought Exercise: Is This Increment Ready?
Work through this scenario to practice using acceptance criteria and traceability to judge readiness.
Scenario:
You are the BA on an agile team that just finished an iteration for an e-commerce site. The iteration goal was to add a "Save for Later" feature to the shopping cart.
Acceptance criteria for the main story include:
- Users can move items from cart to "Saved for Later" with one click.
- Saved items persist for at least 30 days for logged-in users.
- Saved items do not count toward cart totals.
- Events are logged for analytics when items are saved or moved back to cart.
Additional context from the requirements traceability matrix:
- Requirement R-AN-01: "Marketing must be able to see how often items are saved for later versus purchased."
- Requirement R-UX-02: "Cart page must load within 3 seconds for 95% of users at peak load."
Test results:
- Functional tests for criteria 1–3 passed.
- Logging events (criterion 4) are implemented but not yet integrated with the analytics tool, so marketing cannot see the data.
- Performance testing shows cart load time at 3.5 seconds during peak.
Reflect and jot down answers:
- Would you recommend releasing this increment to all users now? Why or why not?
- Which requirements in the traceability matrix are not fully satisfied?
- What additional acceptance criteria or nonfunctional tests would you propose for future iterations?
You do not need to submit answers, but try to argue your position as if explaining it to a product owner and a compliance stakeholder.
Quick Check: Backlog, Roadmap, and Traceability
Test your understanding of how these agile artifacts work together.
Which statement best describes the relationship between a product backlog and a requirements traceability matrix in an adaptive project?
- The product backlog replaces the requirements traceability matrix, so the matrix is not needed in agile.
- The requirements traceability matrix orders the work, while the product backlog only stores historical requirements.
- The product backlog manages and orders current work items, while the requirements traceability matrix links those items back to their originating requirements and forward to tests and deliverables.
- They are identical documents with the same purpose, just using different formats.
Show Answer
Answer: C) The product backlog manages and orders current work items, while the requirements traceability matrix links those items back to their originating requirements and forward to tests and deliverables.
In adaptive projects, the product backlog holds and orders current and upcoming work items. The requirements traceability matrix provides end-to-end links from origin (business need, regulation) through backlog items to design and tests. Agile teams often use both together; the backlog does not replace the matrix.
Quick Check: Validation in Predictive vs Adaptive
Compare how validation works across life cycles.
Which scenario best illustrates validation of requirements in an adaptive life cycle?
- At the end of the project, the sponsor signs a single formal acceptance document after a final inspection of all deliverables.
- At the end of each iteration, stakeholders review working features in a demo, provide feedback, and the product owner accepts or rejects items based on predefined acceptance criteria and test results.
- At project kickoff, stakeholders approve a detailed requirements specification that will not change during the project.
- Midway through the project, the project manager updates the Gantt chart without involving stakeholders and declares that all requirements will be validated later.
Show Answer
Answer: B) At the end of each iteration, stakeholders review working features in a demo, provide feedback, and the product owner accepts or rejects items based on predefined acceptance criteria and test results.
Adaptive life cycles emphasize frequent validation. At the end of each iteration, stakeholders see working increments, provide feedback, and the product owner accepts or rejects items using acceptance criteria and test evidence. Formal one-time sign-off is more typical of predictive approaches.
Key Terms Review: Agile Requirements Artifacts
Use these flashcards to reinforce core definitions you must recall accurately on the CAPM exam.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.
- 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.
- product roadmap (concept)
- A visual, time-oriented plan that shows how major product outcomes, features, or epics will be delivered over time to support strategy. It connects high-level vision to the product backlog.
- release (in agile)
- A deployable package of functionality that delivers value to users, often combining the results of several iterations.
- solution evaluation metrics
- Measurable pre- and post-implementation indicators (such as error rates, cycle times, conversion rates) used to determine whether a solution delivered the expected business value.
- gap analysis (current vs future state)
- A comparison of current-state capabilities with desired future-state capabilities across people, process, policy, and technology to identify the changes required.
Predictive vs Adaptive Validation: Comparing Patterns
Predictive Validation Pattern
Predictive life cycles fix scope, time, and cost early. Validation happens mainly in later phases with formal user acceptance testing and sign-offs at milestones.
Adaptive Validation Pattern
Adaptive life cycles validate continuously. Each iteration ends with a review of working increments, and items are accepted or rejected using acceptance criteria.
Role of Backlog and Metrics
In adaptive projects, the backlog evolves based on feedback and solution evaluation metrics. After each release, metrics guide backlog changes and roadmap updates.
BA Techniques in Each
Predictive projects may rely on large, formal evaluations near the end. Adaptive projects use segmented evaluation, closing gaps incrementally across releases.
Exam Cues
If a scenario mentions frequent demos, evolving backlogs, and incremental acceptance, choose answers that emphasize iterative validation and learning over single sign-offs.
Key Terms
- release
- In agile, a deployable package of functionality that delivers value to users, often combining the results of several iterations.
- user story
- A common agile format for expressing a requirement from a user perspective, often phrased as: "As a [user role], I want [capability] so that [business value]."
- gap analysis
- A comparison of current-state capabilities with desired future-state capabilities across people, process, policy, and technology to identify required changes.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- product roadmap
- A visual, time-oriented plan that shows how major product outcomes, features, or epics will be delivered over time to support strategy and connects vision to the product backlog.
- 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.
- solution evaluation
- The business analysis activity of assessing whether a delivered solution meets the defined needs and expected business value, often by comparing pre- and post-implementation metrics.
- predictive life cycle
- A development life cycle in which the project scope, time, and cost are determined in the early phases of the life cycle.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.