Develop Scope Structure
| Scope/Planning/Develop Scope Structure | ||
|---|---|---|
| Inputs | Tools & Techniques | Outputs |
Inputs, tools & techniques, and outputs for this process.
The practice of organizing approved scope into a clear, hierarchical or value-based structure (e.g., WBS or story map) that defines deliverables, boundaries, and acceptance criteria to enable planning, estimating, and control.
Purpose & When to Use
- Turn broad objectives and requirements into an organized view of what will be delivered and what work is needed, so teams can plan, estimate, and track progress effectively.
- Clarify product and project scope, boundaries, and acceptance criteria to reduce ambiguity and rework.
- Enable cost, schedule, risk, and quality planning by defining manageable chunks of scope.
- Use at project start, at the beginning of each phase or release, when major changes occur, and before significant procurement or make/buy decisions.
- Applies to predictive (deliverable-based WBS), adaptive (story map/backlog hierarchy), and hybrid approaches.
Mini Flow (How It’s Done)
- Gather inputs: charter or vision, business goals, requirements or backlog, constraints, assumptions, and stakeholder expectations.
- Select a structuring approach: deliverable-based WBS for predictive; story mapping or feature/capability breakdown for adaptive; combine as needed for hybrid.
- Decompose scope: break outcomes into deliverables, features, and then work packages or user stories that are small enough to estimate and manage.
- Define acceptance criteria and completion rules for each deliverable, feature, or story, including quality and nonfunctional needs.
- State boundaries explicitly: what is in scope and what is out of scope, including interfaces and external dependencies.
- Validate with stakeholders: confirm completeness, no overlaps, and alignment with value, constraints, and priorities.
- Baseline or govern: in predictive, approve the scope baseline (structure plus descriptions and boundaries); in adaptive, agree backlog policies for ordering, refinement, and change.
- Link for planning and control: connect work packages to the schedule, cost accounts, and risks; link backlog items to releases or iterations and definitions of done.
- Maintain traceability: map requirements to deliverables and verification methods; update the dictionary or item details as scope evolves.
- Manage changes: evaluate proposed changes, update the structure, criteria, and traceability, and communicate decisions to all stakeholders.
Quality & Acceptance Checklist
- All approved scope is represented once with no gaps or overlaps.
- The organizing principle is clear (deliverable, feature, capability, or value slice).
- Each element has a concise description and acceptance criteria.
- Work packages or stories are sized for reliable estimating and ownership.
- In-scope and out-of-scope statements are explicit and understood.
- Nonfunctional requirements and compliance needs are included where relevant.
- Interfaces, external dependencies, and handoffs are identified.
- Unique IDs, responsibility, and version or date are assigned to each element.
- Requirements-to-deliverable traceability is established and current.
- Baseline approval or backlog governance decisions are recorded and communicated.
Common Mistakes & Exam Traps
- Mixing activities or team names into the structure instead of focusing on deliverables or value.
- Decomposing too deeply (administrative tasks) or not enough (items too large to estimate and control).
- Skipping stakeholder validation, leading to missed scope or duplicated work.
- Ignoring nonfunctional or regulatory requirements until late in delivery.
- Confusing product scope (features and qualities) with project scope (work to deliver them).
- Assuming the structure is static; failing to update after approved changes or learning.
- For adaptive teams, treating the backlog as a to-do list of tasks rather than value-oriented slices.
- Believing the WBS or story map is the schedule; activities and sequencing come after scope is structured.
- Not maintaining traceability from requirements to deliverables and tests.
PMP Example Question
A project team completed a deliverable-based scope structure and drafted acceptance criteria. What should the project manager do next to ensure scope control and traceability?
- Convert work packages directly into scheduled activities and lock the schedule.
- Approve the scope structure with its descriptions or backlog policies and link items to requirements and verification methods.
- Create a communications plan to share the structure with stakeholders.
- Request sponsor approval of the cost baseline to prevent scope changes.
Correct Answer: B — Approve the scope structure with its descriptions or backlog policies and link items to requirements and verification methods.
Explanation: Formalizing the scope structure (baseline or governance) and establishing traceability enables effective change control and verification. Scheduling or cost approval alone does not ensure scope control.
HKSM