Scope – everything we agree to address in the project.
This task, “Plan and Manage Scope,” is integral to all the following planning, executing, controlling and tracking activities. We need to understand what is in scope for the project and, just as importantly, what is out of scope to correctly plan, estimate and schedule the work.
2.8.1 Determine and Prioritize Requirements
Two plans that are used to define and explain how the project scope will be tracked and managed are:
- Scope Management Plan – How the overall scope will be specified and managed. This defines the boundaries of what is in scope and out of scope and how we will oversee this scope.
- Requirements Management Plan – How the individual scope elements, the requirements declared as in scope will be analyzed, documented and managed.
Scope Management Plan – A sub-section of the project management plan that describes how the scope will be described, built, monitored, controlled, and validated. Think of this as the boundary or perimeter of the project. Everything inside we will do; everything outside we will not.
The Scope Management Plan describes the wall around our garden and how things get in and out. What is inside are our requirements.
Project Requirement – The agreed capabilities of a product, service, or outcome that the project is designed to provide or satisfy. I.E., The things we are on the hook for creating or doing.
Requirements Management Plan – another sub-section of the project management plan that describes how the project and product requirements agreed as in-scope will be analyzed, documented, and managed. It may also include a description of the requirements configuration management, prioritization processes and traceability matrix.
There are several ways to identify and capture requirements. Some of the popular ones are shown below:
Let’s briefly review each approach:
Document Analysis – Gathering project requirements from evaluating current documentation. These documents include business plans, product descriptions, other marketing materials, strategy documents, process diagrams, competitor product documentation.
Brainstorming – A technique to generate and collect multiple ideas related to product or project requirements.
Focus Groups – bringing together prequalified stakeholders and subject matter experts to learn about their ideas and expectations for a product or service.
Questionnaires and surveys – Written sets of questions designed to quickly gather information from a large number of respondents. They can be handy when a quick turnaround is needed or to make statistical analysis more straightforward.
Interviews – Talk directly to stakeholders and ask them what they want or need from a project. They can be conducted one-to-to or in group settings.
Benchmarking – Comparing actual or planned products, processes, services and practices to those from other organizations to get ideas for improvement or requirements. “We benchmarked the features of other project management tools to see what our product features should contain.”
Facilitated Workshops – combining some elements of focus groups, brainstorming and interviews, these facilitated sessions to elicit candidate features from stakeholder groups. They are also used by some agile approaches to generate the initial product backlog.
Observation – Watching and listening to gain knowledge of a specific job role, task, or function to understand and determine project requirements.
Agile approaches emphasize a customer-centric view of requirements gathering. The product owner is usually recruited from the business, not the group doing the product development, to ensure that customer requirements drive the project prioritization. Engaging customer representatives throughout the project at demonstrations also help ensure customer requirements are kept in focus.
Analyzing and Understanding Requirements
It is not enough to collect requirements; teams need to analyze and understand them too. This is achieved through techniques such as creating context diagrams, storyboards and prototypes.
Requirements Traceability Matrix
Requirements traceability is the ability to connect requirements to other artifacts, such as tests or defect reports. A Requirements Traceability Matrix (RTM) is used to track requirements and document that they have been fulfilled.
2.8.2. Break Down Scope (e.g., WBS, backlog)
After capturing the requirements, we need to break them down to the appropriate level of detail. This helps show dependencies and allows for activities such as estimation and scheduling. Traditional, plan-driven projects use work breakdown structures to manage work items. Agile and hybrid approaches use backlogs. We will examine each in turn.
Traditional, plan-driven projects attempt to capture all the project scope in advance. Then break it down into granular elements for analysis, estimation and scheduling. The mindset is “Plan the work, work the plan.” This works great for projects that are primarily knowable in advance. However, for project environments with high rates of change and uncertainty, agile and hybrid approaches offer alternative structures.
Work Breakdown Structure (WBS)
The WBS 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. It also shows the work in the currently approved project scope statement.
Decomposition is the process of dividing the 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. These are also the lowest level of the WBS with a unique identifier.
The level of decomposition is often based on the degree of control needed to manage the project. So, the level of detail for work packages varies with the size and complexity of the project.
A WBS dictionary is a document that lists the deliverable, activity, and scheduling information about each component in the WBS. It contains details about the task, such as:
- A description of the work
- Cost estimations
- Quality requirements
- Acceptance criteria
- Any assumptions and constraints
- Schedule milestones
- Associated schedule activities
- People and resources required to complete the work
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 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.
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!)
When there is a lot of uncertainty, complexity or change rates are high, it is not viable to adopt a “Plan the work, work the plan” mindset. Instead, agile approaches build increments of what is known, prioritized and practical right now. Then use evaluations of these increments to steer product development.
For agile projects (and hybrid using agile scope management), the overall scope management process and decomposition of features with projects looks like this.
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).
The product backlog is the container for project scope items. In this regard, it is similar to a WBS, but in others, quite different. It is prioritized by business value (and potentially risk), so not all entries are created equally. The items near the top of the backlog will be more detailed and better defined. Items near the bottom (lower priority) will have less detail.
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 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.
This product backlog hierarchy mimics a WBS structure hierarchy in some ways. It contains a roll-up and decomposition to a level that supports understanding details, estimation and defining acceptance criteria. Much of the WBS dictionary, control accounts and planning package information is contained in the backlog, user story information and acceptance criteria. You can read more about the similarities and differences between WBS and Product backlogs here.
As mentioned, user stories are the central planning unit for agile approaches. As the name suggests, it is a user-focussed story or explanation about some desired functionality. Taking a customer-centric view of requirements helps ensure we build products and services that are valuable.
The story components describe who is asking for the feature, what the feature is, and why that is valuable. These components of a story are often contained within the user story pattern:
As a <Role> I want <Functionality> to <Business Benefit>
For example, “As a <Video Conferencing user>, I want to <Sign in to 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 helps remind teams how to write, structure and develop robust and effective user stories.
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.
2.8.3 Monitor and Validate Scope
As the project executes, we need to make sure we are developing the scope correctly, and it is accepted.
Traditional Projects use a variety of tools and techniques to monitor and confirm scope:
Validate Scope – Actions to review and approve work packages and deliverables meet the acceptance criteria defined in the WBS dictionary. For example, performing quality checks on project outputs and updating the requirements traceability matrix.
Variance Analysis – A review technique for determining the cause and degree of difference between the baseline and the actual performance. For example, comparing deliverables produced for a period against those listed on the baselined plans for the same period.
Trend Analysis – Looking for trends in data. Using extrapolation or more complex mathematical models to forecast future outcomes based on historical results. For example, predicting if the number of near-miss safety concerns continues, we can expect a safety incident if we do not change on-site behavior.
Agile approaches use the above techniques too, but place more emphasis on the following agile focussed tools and techniques:
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 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?
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 in to 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. )
Iteration Reviews – At the end of every iteration, the team demonstrates the functionality built in that timebox. These iteration reviews (Sprint demos) allow the business and other stakeholders to see how the project scope and delivery are progressing.
They act as frequent checkpoints to validate scope and flush out any misunderstandings. Variations of the swing cartoon have been used for over 30 years to describe common mismatches in stakeholder understandings.
A solution for the problems characterized in the swing cartoon is frequent review and verification of product increments.
This is what we get from the Sprint demos (iteration reviews). Instead of a nasty surprise at the end of the project, we see the ongoing progress. This progress might be frustratingly slow or potentially in the wrong direction, but it only represents one iteration’s worth of work. These reviews provide opportunities to intervene if what is being developed diverges from what is required.
Deliverables and Tools
- Requirements register
- Work performance reports
- Traceability matrix
- Agile estimating
- Product backlog
- Document change requests
- Update project management plan
- 2.1 Execute project with the urgency required to deliver business value
- 2.3 Assess and manage risks
- 2.4 Engage Stakeholders
- 2.5 Plan and manage budget and resources
- 2.6 Plan and manage schedule
- 2.7 Plan and manage quality of products/deliverables
- 2.9 Integrate project planning activities
- 2.10 Manage project changes
- 2.11 Plan and Manage Procurement
- 2.12 Manage Project Artifacts
- 2.13 Determine appropriate project methodology and practices
- 2.14 Establish project governance structure
- 2.15 Manage project issues
- 3.3 Evaluate and address external business environment changes
0 of 3 Questions completed
You have already completed the quiz before. Hence you can not start it again.
Quiz is loading…
You must sign in or sign up to start the quiz.
You must first complete the following:
0 of 3 Questions answered correctly
Time has elapsed
You have reached 0 of 0 point(s), (0)
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
Congratulations! You score 100% and won the 2.8 Manage Scope Badge.
(Must be logged in to be awarded badges)
See your achievements
|Table is loading|
|No data available|