"Scope creep" has always been the bane of traditional project managers. Requirements constantly change in response to customer business needs, shifts in the industry, advances in technology, and things that were learned during the development process. Scope planning, definition, verification, and control are all knowledge areas that are given a great deal of attention in the PMBOK. These areas garner great attention in agile methodologies as well, but the 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 cost and schedule and then work to implement the highest value features as defined by the customer, so that scope remains flexible. This is contrasted against a typical waterfall approach as illustrated in Figure 1, where features (scope) first are defined in detail, driving the cost and schedule estimates. Agile has simply flipped the triangle in detail, driving the cost and schedule estimates.

Figure 1: Waterfall versus agile: the paradigm shift

The project "box" used is one of time. However, instead of stuffing more feature "bricks" into a single flimsy box until the timebox explodes, we use multiple timeboxes made of steel and stop adding bricks when the box is full. Then the box is "padlocked" for that iteration and only the features in that box (iteration) are worked through to acceptance. But because we're doing this box loading and padlocking one iteration at a time, it's difficult to understand how much work will be completed in a longer timeframe. Agile uses techniques such as release planning to estimate what that longer timeframe might look like.

The PMBOK practices of scope definition, work breakdown structure (WBS) creation, and scope verification occur iteratively in agile. During release planning, the features are defined at a very high level and placed into iterations in priority order. At this point the WBS only has deliverables, not work packages. These features, or deliverables, can be estimated at a gross level only. Once the iteration begins, the features slated for that iteration--and only that iteration--are elaborated. Think of it as just-in-time elaboration that prevents a wasteful buildup of requirements inventory that may never be processed. At the end of release planning, the agile equivalent of a WBS would look like the release plan in Figure 2.

Figure 2: Release Plan

Figure 3: Partial Iteration Plan

Scope definition and many of the practices defined in the PMBOK knowledge area of Project Time Management are done as part of iteration planning, where features are elaborated (creating PMBOK work packages or agile user stories), tasked out, estimated, and assigned (see Figure 3). Again, planning and design work is done only for the features in that iteration, not on the entire system. Duration is no longer of interest in an agile project, because it is always the length of the iteration--the steel box that we're putting our features into, which won't change. Estimations are now based on the amount of work effort needed for each of the tasks, and it's the entire team--not just the project manager--that does the estimating. Team members sign up for the tasks instead of simply being assigned to them. This gives the team an opportunity to commit to the schedule and take ownership of the work.

The critical path is no longer identified. Project managers instead focus on impediments to completing the work by using Dr. Eli Goldratt's "Theory of Constraints" and critical chain method. Think of the constraints in your project as kinks in a garden hose. It's your job to make the project flow, which you do by eliminating one kink at a time. The highest priority features then can be worked through to acceptance, by completing chunks small enough to have potentially shippable software ready for use at the end of each iteration.

Scope verification is accomplished within each iteration, as customers get 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 into the backlog or into the next iteration. The management of this backlog addresses scope change control, as discussed in Part 1 of this series of articles.

You can see that PMBOK best practices aren't really that different from agile methods; they're simply done more often, iteratively and incrementally, with the attention to detail that's appropriate for the timeframe. This means that scope has the potential to change at the end of every iteration, as new information is learned about the technology and the customer's preferences. And because it's the customer who's deciding what the team should work on next, satisfaction rates rise with every iteration.

In my next article, the third in this four-part series, I'll discuss quality management and risk management in agile projects.

Click Here to Read Relating PMBOK Practices to Agile Practices Part 1 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 3 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 4 of 4