Home > Articles > Software Development & Management > Agile

The Software Project Manager's Bridge to Agility: Scope Management

📄 Contents

  1. Scope Planning
  2. Summary
"Scope creep" doesn't exist in agile projects, because scope is expected to change. This chapter covers how agile managers can plan for and handle changes in a project's scope.
This chapter is from the book
  • Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
  • —PMBOK® Guide
  • It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.
  • Charles Darwin, The Origin of Species
  • Next week there can't be any crisis. My schedule is already full.
  • Henry Kissinger

"Scope creep" has always been the bane of traditional project managers, as requirements continue to change in response to customer business needs, changes in the industry, changes in technology, and things that were learned during the development process. Scope planning, scope definition, scope verification, and scope control are all processes that are defined in the PMBOK® Guide to prevent scope creep, and these areas earn great attention from project managers. Those who use agile methods believe these deserve great attention as well, but their philosophy on managing scope is completely different. Plan-driven approaches work hard to prevent changes in scope, whereas agile approaches expect and embrace scope change. The agile strategy is to fix resources and schedule, and then work to implement the highest value features as defined by the customer. Thus, the scope remains flexible. This is in contrast to a typical waterfall approach, as shown in Figure 5-1, where features (scope) are first defined in detail, driving the cost and schedule estimates. Agile has simply flipped the triangle.

Figure 5-1

Figure 5-1 Waterfall vs. Agile: The paradigm shift (original concept courtesy of the DSDM Consortium)

Scope Planning

The PMBOK® Guide defines the Project Scope Management Plan as the output of the scope planning process.1 This document defines the processes that will be followed in defining scope, documenting scope, verifying and accepting scope and completed deliverables, and controlling and managing requests for changes to the scope. In agile, the iterative and incremental process itself is what manages scope. Unless documentation is required for auditing purposes, no additional document outlining procedures for scope management is needed. Scope is defined and redefined constantly in agile, as part of the planning meetings—in particular, release planning and iteration planning—and by the management of the product backlog. Remember, resources and time are typically fixed in agile approaches, and it's the scope that is allowed to change. However, when fixed-scope projects are required, it is the number of iterations that will change, in order to accommodate the need for a full feature set prior to release. Additionally, one of the success criteria in traditional projects is the extent to which we can "stick to the scope"; in agile, it is more important to be able to efficiently and effectively respond to change. The success criteria in agile thus changes to "Are we providing value to our customer?" The primary measure of progress is working code.

Table 5-1 provides a summary comparison of scope planning from the traditional and agile perspectives. In agile projects, scope planning is referred to as "managing the product backlog."

Table 5-1. Scope Planning

Traditional

Agile

Prepare a Project Scope Management Plan document.

Commit to following the framework as outlined in the chosen agile process.

Scope Definition

The PMBOK® Guide practices of scope definition, work breakdown structure (WBS) creation, and scope verification occur iteratively in agile. A traditional WBS for software projects is usually divided at its highest level into phases of analysis, design, coding, testing, and deployment activities. Each of these phases is then decomposed into tasks or groups of tasks, referred to as work packages in the PMBOK® Guide. Traditional project planning begins top-down and relies on the elaboration of detailed tasks with estimates and dependencies to drive the project schedule via use of critical path analysis. Even though the PMBOK® Guide goes into great detail about scope decomposition by way of WBS (work breakdown structure), it also warns that "excessive decomposition can lead to nonproductive management effort, inefficient use of resources, and decreased efficiency in performing the work."2

In agile, we approach these practices differently in that we define features at a high level in the product backlog and then place features into iterations during release planning. One can think of the iteration—or even the feature itself—as the agile equivalent of work packages. The features are estimated at a gross level in the product backlog—no detailed tasks or resources are defined at this point in time. Once the iteration begins, the features slated for that iteration—and only that iteration—are then elaborated into tasks that represent a development plan for the feature. Think of it as just-in-time elaboration, preventing a wasteful buildup of requirements inventory that may never be processed. The PMBOK® Guide supports this idea of "rolling wave planning":3 As the work is decomposed to lower levels of detail, the ability to plan, manage, and control the work is enhanced because the short timeframe of the iteration reduces the amount of detail and the complexity of estimating. The agile approach assumes that because things change so often, you shouldn't spend the time doing "excessive decomposition" until you're ready to do the work.

Let's look at how scope is defined throughout an agile project by examining five levels of planning common to most agile projects: the product vision, the product roadmap, the release plan, the iteration plan, and the daily plan.4

Product Vision

At the outset of a project, it is typical to hold a kickoff meeting. Agile is no different; however, the way the agile vision meeting is conducted is unlike what a traditional project manager might be accustomed to. Although the vision is defined and presented by the customer or business representative, it is the team that clarifies the vision during the discussions and subsequent exercises. Therefore, the team is heavily involved, and group exercises are a big part of determining the final outcomes. See Chapter 4, "Integration Management," for more detail on vision meetings.

The vision meeting is designed to present the big picture, get all team members on the same page, and ensure a clear understanding of what it is that they've been brought together to do. The vision defines the mission of the project team and the boundaries within which they will work to achieve the desired results. The project's goal should be directly traceable to a corporate strategic objective.

Here the scope is defined at a very high level. It is not uncommon to leave the vision meeting with only a dozen or so features identified, such as "provide online order capabilities," "enable international ordering and delivery," "create data warehouse of customer orders to use for marketing purposes," and "integrate with our current brick-and-mortar inventory system." Clearly these are all very large pieces of functionality with little-to-no detail—and this is what is appropriate at this stage of the project. The farther away the delivery date, the broader the stroke given to feature details.

Product Roadmap

A product roadmap shows how the product will evolve over the next three to four releases or some period of calendar time, typically quarters. The product roadmap is a high-level representation of what features or themes are to be delivered in each release, the customer targeted, the architecture needed to support the features, and the business value the release is expected to meet. The customer or product manager, agile project manager, architect, and executive management should meet on average two to three times a year to collaborate on the development and revision of the product roadmap. Figure 5-2 shows a sample roadmap template made popular by Luke Hohmann in his book Beyond Software Architecture.5

Figure 5-2

Figure 5-2 Product roadmap template, courtesy of Enthiosys and Luke Hohmann, from his book Beyond Software Architecture

Because the customer is responsible for maintaining and prioritizing the backlog of work, the customer also owns the product roadmap. In large corporations or on projects with multiple customers or product owners, the customer assigned to the project will often first work with others in his business unit to create a roadmap straw man as part of working out the priorities of deliverables with the business. Then this straw man is presented to key project team members (agile project manager, architect, and so on) for further revision. Finally, the roadmap is presented to the entire team and interested stakeholders, usually as part of the vision meeting and/or release planning meeting. Feedback is encouraged at all sessions because it helps to better define a reasonable approach to product deliverables.

In addition to the vision plan and product roadmap, the end result of the product vision and product roadmap discussions should be the prioritized product backlog. These are all inputs into the next level of planning: release (or quarterly) planning.

Release (or Quarterly) Planning

In a release planning meeting, the team reviews the strategies and vision shared by the customer and determines how to map the work from the prioritized backlog into the iterations that make up a release or that make up a period of time such as a quarter. Figure 5-3 shows a typical release plan agenda, and Figure 5-4 shows the release plan done using a whiteboard and sticky notes, as is common in agile meetings when the team is co-located. The release plan is divided up into iterations (usually one flipchart page per iteration), with associated high-level features. The release plan also includes any assumptions, dependencies, constraints, decisions made, concerns, risks, or other issues that may affect the release. Again, documentation of these additional items can be as simple as posting the flipchart that they were originally recorded on or taking a picture of it and posting it on a shared website.

Figure 5-3

Figure 5-3 Release planning meeting agenda

Figure 5-4

Figure 5-4 Release plan

Teams that are not co-located should make every effort to bring everyone together for this meeting. Agile emphasizes face-to-face communication because of its benefits. However, balancing this with the realities of geographically dispersed teams means that budget constraints force teams to be selective about when they can gather together as a group. The vision and release planning meetings should receive high priority, because the information shared and decisions made in these meetings guide the team throughout the remainder of the release.

Iteration Planning

Traditional scope definition and many of the practices defined in the PMBOK® Guide knowledge area of Project Time Management are done as part of iteration planning. Here, features are elaborated (creating the equivalent of PMBOK® Guide work packages), tasks are identified, and the time needed to accomplish the tasks is estimated (see Figures 5-5 and 5-8). At the beginning of each iteration, the team should hold an iteration planning meeting to conduct this work. The team reviews the release plan and the prioritized items in the backlog, reviews the features requested for the current iteration, and tasks out and estimates those features. See Figure 5-6 for a typical iteration planning meeting agenda. In keeping with the agile practice of just-in-time design, it is here that the details of the features are discussed and negotiated.

Figure 5-5

Figure 5-5 Iteration plan

Figure 5-6

Figure 5-6 Iteration planning meeting agenda

Again, planning and design work is done only for the pieces that are being readied to code in that iteration, not for the entire system. It's often discovered during iteration planning that the sum of the task efforts exceeds the size of the iteration timebox. When this occurs, some of the work needs to be shifted either into the next iteration or back into the backlog. Similarly, if a team discovers that it has chosen too little work for the iteration, it will consult with the customer, who can then give the team an additional feature or two to make up the difference. This allows the team to make a realistic commitment to the scope of the work being defined.

Daily Stand-Up

One of the key heartbeats of agile development involves the practice of daily stand-up meetings. It is just what it sounds like: a daily meeting, where all team members attend, and while remaining standing, they each relate their status to the other team members and their plan for the day based on the progress that they've made. Standing helps keep the meetings short—stand-ups should run only 5 to 15 minutes. Its primary purpose is for the team members to inspect and adapt its work plan (iteration backlog) by quickly sharing information about the progress (or lack of) being made by each individual regarding the tasks that were committed to during the iteration planning meeting. These stand-ups help the team to remain focused on the agreed-to scope and goals of the iteration.

Summary Comparison

Table 5-2 provides a summary comparison of traditional and agile approaches to scope definition. In agile projects this is called "multilevel planning."

Table 5-2. Scope Definition

Traditional

Agile

Prepare a Project Scope Statement document that includes items such as the following:

Project boundaries and objectives, product scope description...

Conduct a vision meeting to share the product vision; confirm and clarify the boundaries, objectives, and product scope description using exercises such as the elevator statement and design the box.

And major milestones and project deliverables...

Conduct a planning meeting to prepare the product roadmap, as well as release or quarterly planning meetings that also include milestones and deliverables at an iteration level.

And product specifications and acceptance criteria...

Conduct an iteration planning meeting that results in the detail around each feature, and the tasks needed to complete the feature according to the team's definition of "done" and the acceptance criteria defined by the customer.

And assumptions and constraints.

All planning meetings identify and/or review assumptions and constraints.

Create a WBS

Agile teams do not tend to create formal WBSs (work breakdown structures). Instead, flipcharts and whiteboards are used to capture the breakdown of work. You've seen examples of these in Figures 5-4 and 5-5. So at the end of release planning, the agile equivalent of a WBS—a feature breakdown structure—would look like the sample release plan feature breakdown structure in Figure 5-7. If having iterations as work packages is not sufficient for your organization/billing needs, then breaking the work down further into smaller work packages would look like the results of an iteration planning meeting, as illustrated in Figure 5-8.

Figure 5-7

Figure 5-7 Release plan feature breakdown structure

Figure 5-8

Figure 5-8 Iteration plan (partial)

Table 5-3 compares the traditional and agile approaches to work breakdown. In agile projects, the work breakdown structure is captured in the release plan and the iteration plan.

Table 5-3. WBS Creation

Traditional

Agile

Create a work breakdown structure diagram.

Conduct planning meetings and give the team the responsibility for breaking down the work into smaller work packages (features and tasks), displayed as the release plan at the high level, and the iteration plan at the more detailed level.

Scope Verification

Scope verification is accomplished within the iteration, as the customer gets to review, test, and accept the implemented features. Ideally this happens throughout the iteration, but it can also happen at the end of the iteration, during the demo of the working code. Those features that were not accepted (either because they weren't ready or weren't right) move back into the backlog or into the next iteration at the discretion of the customer. Scope change control is handled by the management of this backlog, as discussed in the previous chapter on integration.

Table 5-4 makes the comparison between the traditional and agile approaches to scope verification. Scope verification is captured by the agile practices of acceptance testing and customer acceptance.

Table 5-4. Scope Verification

Traditional

Agile

Document those completed deliverables that have been accepted and those that have not been accepted, along with the reason.

Documentation of accepted features may be done informally (by moving the sticky notes to the "done" pile) or formally

Document change requests.

Customer updates the backlog.

Scope Control

Controlling scope in agile projects consists of two things: managing the product backlog and protecting the iteration. Whereas the customer maintains the backlog, it is the agile project manager who protects the team and helps prevent scope changes from occurring during the iteration.

When a team commits to the iteration at the end of the iteration planning meeting, the delivery team is effectively saying, "Given what we know today, we believe we can deliver this work using our definition of 'done' within this iteration," and the customer is effectively saying, "Given what I know today, this is the work that I am expecting by the end of the iteration, and during that time I will not mess with the iteration backlog" (that is, scope). The iteration backlog is thus locked in.

It is important to set the length of your iteration accordingly, because the customer must wait until the next iteration to make changes. If there happens to be lots of "requirements churn" (that is, requests for changes are coming in very frequently), you may want to discuss shorter iteration cycles with the team in order to enable more frequent changes. Maintenance teams may have iteration lengths of only one week, whereas larger system developments with known requirements may have an iteration length of four to six weeks. If the customer keeps trying to interrupt the team with changes, the iteration length may be too long.

There will always be exceptions, and in those cases a discussion between the customer and the agile project manager should help identify potential resolutions. Iterations can be aborted and restarted, but this should be the rare exception.

Given the short duration of iterations, it is easy to protect the iteration backlog from change. However, changes in the product roadmap and the release plan are expected and therefore should be reviewed regularly.

Table 5-5 lists out the differences between the traditional and agile approaches to scope control. Agile users refer to scope control as "managing the product backlog."

Table 5-5. Scope Control

Traditional

Agile

Use a change control system to manage change.

The customer manages the product backlog; once the team commits to the work to be done in an iteration, the scope is protected for that duration.

Update all documents as appropriate with the approved changes.

The team revisits release plans and product roadmaps regularly, making changes as needed to better reflect the team's progress and changes requested by the customer.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020