Key Concepts
Scope is everything the project agrees to address, and it is where projects often run into trouble. Managing scope well means three things: defining it clearly, getting genuine agreement from the people who matter, and breaking it into pieces you can plan, estimate, and track.
Scope is everything we agree to address in the project. It sounds simple, but scope is where more projects run into trouble than almost anywhere else. Teams build the wrong thing, sponsors discover late that their expectations were never captured, and customers receive a product that technically meets the written requirements but misses the point entirely.
Managing scope well means three things:
- Defining it clearly
- Getting genuine agreement from the people who matter
- Breaking it into pieces you can plan, estimate, and track.
This task covers all three.
2.2.1 Define Scope
Defining scope starts with understanding what the project is expected to deliver. This means identifying requirements, but it also means being explicit about what is out of scope. A clear out-of-scope boundary prevents the silent creep of assumptions as much as a good requirements document prevents misunderstandings.
Scope Management Plan
The scope management plan describes how the scope will be specified, built, monitored, controlled, and validated. Think of it as the boundary of the project. Everything inside that boundary will be done; everything outside will not.
Agile projects do not typically produce a formal scope management plan. The product backlog serves as the living container for project scope. The product owner manages what is in and out of scope by maintaining backlog priorities, adding new items, removing lower-value ones, and making the current scope visible to all stakeholders. The team’s working agreement and any project charter set the outer boundaries.
Requirements Management Plan
The requirements management plan describes how the individual scope elements agreed as in-scope will be analyzed, documented, and managed. It covers configuration management for requirements, prioritization processes, and the structure of the requirements traceability matrix.
Agile teams manage requirements through user stories and backlog refinement rather than a formal requirements management plan. Stories are written, estimated, accepted, and refined continuously. Backlog refinement sessions, held regularly throughout the project, serve the same function as the requirements management process: keeping requirements current, detailed enough to develop, and prioritized by value.
Collecting Requirements
Requirements can be identified and captured in a variety of ways. Approaches that work across predictive, hybrid, and agile projects include:
Document analysis means gathering requirements from existing materials: business plans, product descriptions, strategy documents, process diagrams, and competitor product documentation.
Brainstorming generates and collects multiple ideas from a group working together. It is fast and inclusive, and it surfaces requirements that individual interviews might miss.
Focus groups bring together prequalified stakeholders and subject matter experts to explore their expectations for a product or service in a structured discussion.
Questionnaires and surveys use written sets of questions to gather information quickly from a large number of respondents. They work well when a fast turnaround is needed or when statistical analysis is useful.
Interviews involve talking directly with stakeholders, either one-to-one or in group settings, to understand what they want or need from the project.
Benchmarking compares planned products, processes, or services to those from other organizations to identify features worth including or practices worth adopting.
Facilitated workshops combine elements of focus groups, brainstorming, and interviews in a structured session to elicit requirements from stakeholder groups. They are among the most efficient ways to align a diverse group around scope in a short time.
Observation means watching and listening to understand a specific job role or task from actual practice rather than from what people say they do.
Agile projects place particular emphasis on customer-centric requirements gathering. The product owner is typically recruited from the business, not the delivery group, so that customer needs drive prioritization from the start. Feature workshops are often used early in the project to brainstorm and develop a candidate feature list collaboratively. Ongoing iteration reviews then serve as a continuous requirements validation loop, surfacing new understanding and correcting misalignments one iteration at a time.
Analyzing Requirements
Collecting requirements is not enough on its own. Teams need to analyze and understand them. Context diagrams, storyboards, and prototypes are useful for surfacing ambiguities and confirming shared understanding before work begins. Making requirements visible in a concrete form, even a rough one, almost always produces better feedback than asking stakeholders to review a written list.
Requirements Traceability Matrix
A requirements traceability matrix connects each requirement to the artifacts associated with it, such as design decisions, test cases, and defect reports. It provides an auditable record that each requirement has been addressed and supports impact analysis when a change is proposed.
Agile projects place particular emphasis on customer-centric requirements gathering. The product owner is typically recruited from the business, not the delivery group, so that customer needs drive prioritization from the start. Feature workshops are often used early in the project to brainstorm and develop a candidate feature list collaboratively. Ongoing iteration reviews then serve as a continuous requirements validation loop, surfacing new understanding and correcting misalignments one iteration at a time.
2.2.2 Obtain Stakeholder Agreement on Project Scope
Defining scope and agreeing on scope are not the same activity. A requirements document can be complete, reviewed, and signed off, and still leave key stakeholders holding different mental pictures of what the project will actually deliver. Agreement means alignment, not just signature.
The root cause of scope disagreement is usually not dishonesty or carelessness. It is the gap between what is written and what people picture when they read it. Scope artifacts are abstractions. The product is concrete. Until people see the product, or a sufficiently close representation of it, they are agreeing to a description rather than to the thing itself.
Several techniques can help here.
Facilitated workshops and feature workshops allow stakeholders to explore scope collaboratively before committing to it. By building shared artifacts together, such as a candidate feature list or a structured backlog, disagreements surface while they are still cheap to resolve.
Prototypes and storyboards make abstract requirements visible. Showing stakeholders a working model or a detailed visual of the end state produces a quality of feedback that written descriptions rarely generate. People react to what they see in a way they rarely react to a written description.
Regardless of life cycle, scope agreement should be formally confirmed. On predictive projects, this means sign-off on the scope baseline by the relevant stakeholders. That signed baseline becomes the reference point for any future scope discussion. On agile and hybrid projects, iteration reviews create a continuous series of agreement checkpoints throughout delivery.
On agile projects, stakeholder agreement is not a single event at the start. At the end of every iteration, the team demonstrates the functionality built in that timebox. Stakeholders confirm whether it meets their expectations. A misalignment discovered at an iteration review represents one iteration of rework at most. The same misalignment discovered at project close can be catastrophic.
Hybrid projects often combine a formal baseline agreement on high-level scope with iterative review and confirmation at the feature and story level during execution.
2.2.3 Break Down Scope
After capturing and agreeing on requirements, scope needs to be broken down to a level of detail that supports estimation, scheduling, and tracking. The right decomposition structure depends on the project approach.
Work Breakdown Structure
The work breakdown structure is a hierarchical decomposition of the project team’s scope of work to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and shows the work contained in the currently approved scope statement.
Decomposition
Decomposition is the process of dividing project scope and deliverables into smaller, more manageable parts. A work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. Work packages carry a unique identifier in the code of accounts and represent the level at which actual performance will be tracked.
The level of decomposition reflects the degree of control needed. Large, complex projects warrant more granular work packages. The level of detail for smaller projects can be lighter while still remaining manageable.
WBS Dictionary
The WBS dictionary provides supporting detail for each component in the WBS. For each work package, it typically includes:
- A description of the work
- Cost and schedule estimates
- Quality requirements
- Acceptance criteria
- Any assumptions and constraints
- Schedule milestones
- People and resources required.
Control Accounts
Organizations tracking performance with earned value can use control accounts to help track actuals to planned values. A control point where the scope, budget, actual cost, and schedule information is integrated and compared to earned value for performance measurement.
Items being tracked this way are identified via a numbering system called a code of accounts.
Planning Packages
Planning packages are any WBS elements below the control account level. They contain known work content but are typically not tracked with detailed schedule activities.
Control accounts, the code of accounts numbering system and planning packages are called out on the following image.
Scope Baseline
The Scope Baseline is the name given to the approved version of the scope statement, the WBS and its associated WBS dictionary and control accounts. It is used for comparison to actual results to gauge performance and can only be changed through formal change control procedures. (To prevent unscrupulous project managers from changing the baseline plan to make it look like the recent delays were planned all along!)
Agile Scope Management
Agile projects do not maintain a fixed scope baseline. The product backlog serves as the equivalent structure: a prioritized, living decomposition of project scope. The backlog is expected to evolve. High-priority items near the top are detailed and ready to develop. Lower-priority items carry less detail and get refined as they move up. This approach means planning effort is concentrated on work that is actually imminent, rather than spent elaborating scope that may never be built.
Many agile projects start with visioning work. A feature workshop helps stakeholders brainstorm and develop a candidate feature list. Working with the product owner, this list becomes the initial product backlog. The team then refines selected backlog items into a sprint or iteration backlog for each cycle. Delivered increments are tested and evaluated during iteration reviews.
Of course, projects don’t just appear. Before a project is created, scope exploration may start with an idea, business case or need for product, service or enhancement. From there, strategic review, portfolio analysis, feasibility, ROI and other decisions are likely made before deciding to kick-off a project.
Many agile projects start with visioning work. The “Design a Product Box” 1) is a common way for project stakeholders to explore and refine scope collaboratively. Then, a Feature Workshop 2) may be used to brainstorm and develop a Candidate Feature List 3).
Working with the product owner, a Product Backlog 4) is created to list the agreed scope. The project team refines the selected backlog items to create a Sprint or Iteration Backlog 5). Finally, the increments of delivered scope get tested and evaluated during acceptance testing and the Iteration Demo 6.
Product Backlog
The product backlog is the container for project scope items on agile projects. It is prioritized by business value, and potentially risk, so not all entries are treated equally. Items near the top are more detailed and better defined. Items near the bottom carry less detail until they move up in priority and warrant further elaboration. This means low-priority items that may get deferred or displaced by higher-priority ones only get refined when they are genuinely likely to be developed.
The backlog hierarchy mirrors a WBS in some ways. It contains a roll-up and decomposition to a level that supports understanding, estimation, and defining acceptance criteria. Much of what lives in a WBS dictionary and its control accounts is captured instead in the backlog, the user story descriptions, and the acceptance criteria attached to each story.
As the project proceeds, items are taken from the top of the backlog to be worked on, the lower priority items move up and get refined with further analysis. This way, low priority items that may get deferred or displaced by high priority items only get elaborated as they become more likely to get developed.
In the backlog diagram above, we see features and user stories. A more complete decomposition of agile scope planning is:
Here, we see groupings of scope are batched up into releases. Each release typically comprises several iterations. Iterations deliver features that can be a user story or a group of user stories. A user story is the smallest chunk of functionality typically prioritized by the product owner. The development team breaks stories down into technical tasks, but these do not always make sense to the product owner or deliver any business value independently.
Release Roadmap
On agile and hybrid projects, the release roadmap provides a higher-level view of planned delivery across multiple iterations. It shows which features or groups of features are targeted for which releases, giving stakeholders a horizon view of when value will be available. The release roadmap is not a fixed commitment. It is updated as the project progresses and actual velocity data replaces initial estimates.
User Stories
User stories are the central planning unit for agile approaches. Each one is a user-focused description of desired functionality, taking a customer-centric view to ensure what gets built is genuinely valuable.
The standard pattern captures who is asking, what the feature is, and why it is valuable:
As a <Role> I want <Functionality> to <Business Benefit>
For example, “As a <Video Conferencing user>, I want to <Sign into my video conferencing sessions using facial recognition on my webcam> to <Avoid entering IDs and passwords>
A product backlog made up of user stories and the main components of a user story are shown below:
The INVEST mnemonic provides a quality check for well-formed user stories. Stories should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. The goal is small, independent, valuable chunks of work that can be estimated and tested, and whose scope can be negotiated with the business to find the right balance of cost versus capability.
I – Independent: Ideally, we want to reprioritize and develop our user stories in any order.
N – Negotiable: The team should discuss stories with the product owner and make trade-offs based on cost and function.
V – Valuable: Why is it important? User stories without clearly understood value will be difficult to prioritize.
E – Estimatable: Can we estimate it, or is it too large or unknown? Making sure we can estimate a story is an important validation it is understood to a sufficient level.
S – Small: Is it small enough to get done in an iteration? Do we need to split it down? People are poor at estimating large chunks of work and they often hide risks and uncertainty. Making sure user stories are small helps reduce these risks.
T – Testable: Will we be able to test it once it’s done? Having testable user stories is essential for tracking progress because agile teams often measure progress based on how many user stories have been successfully accepted.
So, we want small, independent, valuable chunks of work to estimate and test whose functions can be negotiated with the business to find the right level of cost versus performance.
Acceptance Criteria
The set of conditions that are required to be met before deliverables are accepted. In plan-driven projects, acceptance criteria is often recorded in the WBS dictionary. For agile approaches, acceptance criteria is often stored directly in the user story.
Formats such as “Given <Condition>, When <Action>, Then <Correct Outcome>” are sometimes used to capture acceptance criteria. This structure mirrors the “As a <Role>, I Want <Functionality>, To <Business Benefit>” template used to capture user stories.
So, for our earlier example of: “As a <Video Conferencing user>, I want to <Sign into my video conferencing sessions using facial recognition on my webcam> to <Avoid entering IDs and passwords>” we could create some Given, When Then acceptance criteria, such as:
Given <User not signed in and app looking to authenticate>,
When <Approved users face is recognized by the camera >,
Then <Login with that user’s credentials>
(Back in the day when user stories were written on cards. The front of the card would have the “As a <Role>, I Want <Functionality>, To <Benefit>” and the back of the card would have a list of “Given <>, When <>, Then <>” acceptance tests. These days these details are stored in agile project management tools.)
Definition of Ready – This is the team’s checklist for ensuring user stories have all the required information needed for the team to begin working on it.
Examples of a software development team’s Definition of Ready might include:
- Form: A well-defined user story conforming to the INVEST properties
- Testable: The user story acceptance criteria has been defined
- Reasonable Size: Estimated by the delivery team and deemed within the team’s capacity
- Ownership: The person who will accept the user story is identified
- Real: The team will be able to ‘demo’ the user story
Definition of Done
A team’s checklist for ensuring user stories have completed all the necessary steps for it to be truly counted as “Done.”
Examples of a software development team’s Definition of Done might include:
- Tested: Are all unit, integration, and customer tests finished?
- Coded: Has all code been written?
- Designed: Has the code been refactored to the team’s standards and satisfaction?
- Integrated: Does the user story work from end to end and fit into the rest of the software?
- Builds: Does the build script include any new modules?
- Reviewed: Have customers reviewed the user story and confirmed that it meets their expectations?
- Fixed: Have all known bugs been fixed or scheduled as their own user stories?
- Accepted: Do customers agree that the user story is finished?
Deliverables and Tools
- Scope Management Plan
- Requirements Management Plan
- Requirements Documentation
- Requirements Traceability Matrix
- Work Breakdown Structure (WBS)
- WBS Dictionary
- Scope Baseline
- Product Backlog
- Release Roadmap
- User Stories
- Acceptance Criteria
- Definition of Done
- Definition of Ready
- Facilitated Workshops / Feature Workshop
- Prototypes and Storyboards
Related Topics
- 1.4 Engage stakeholders
- 1.5 Align stakeholder expectations
- 1.6 Manage stakeholder expectations
- 2.1 Develop an integrated project management plan and plan delivery
- 2.3 Help ensure value-based delivery
- 2.7 Plan and optimize quality of products/deliverables
- 2.8 Plan and manage schedule
- 2.9 Evaluate project status
- 3.3 Manage and control changes
- 3.5 Plan and manage risk
FAQ
What is project scope?
Everything the project agrees to address.
Why do scope problems happen?
Teams build the wrong thing, sponsors discover late that their expectations were never captured, or customers receive a product that meets the written requirements but misses the point.
What does managing scope involve?
Defining it clearly, getting genuine agreement from the people who matter, and breaking it into pieces you can plan, estimate, and track.
Further Reading
