Chapter 5 Scope Management

1 Chapter 5 Scope ManagementProject Scope Management includes the processes required to ensurethat the project includes all the work required, and only the workrequired, to complete the project successfully. PMBOK GuideIt is not the strongest of the species that survive, nor the mostintelligent, but the ones most responsive to change. Charles Darwin, The Origin of SpeciesNext 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, asrequirements continue to change in response to customer business needs,changes in the industry, changes in technology, and things that were learnedduring the development process. Scope planning , Scope definition, scopeverification, and Scope control are all processes that are defined in thePMBOK Guideto prevent Scope creep, and these areas earn great atten-tion from project managers.

2 Those who use agile methods believe thesedeserve great attention as well, but their philosophy on managing Scope iscompletely different. Plan-driven approaches work hard to prevent changesin Scope , whereas agile approaches expect and embrace Scope change. Theagile strategy is to fix resources and schedule, and then work to implementthe highest value features as defined by the customer. Thus, the Scope 67 4/18/08 3:13 PM Page 67remains flexible. This is in contrast to a typical waterfall approach, as shownin Figure 5-1, where features ( Scope ) are first defined in detail, driving thecost and schedule estimates. agile has simply flipped the triangle. 68 Scope MANAGEMENTF igure 5-1 Waterfall vs. agile :The paradigm shift(original conceptcourtesy of the DSDMC onsortium)Traditional AgileFixedFeaturesResourcesScheduleVaria bleResourcesScheduleFeaturesPlanDrivenVa lue/VisionDrivenAgile flips PlanningThePMBOK Guidedefines the Project Scope Management Plan as the out-put of the Scope planning document defines the processes thatwill be followed in defining Scope , documenting Scope , verifying and accept-ing Scope and completed deliverables, and controlling and managingrequests for changes to the Scope .

3 In agile , the iterative and incrementalprocess itself is what manages Scope . Unless documentation is required forauditing purposes, no additional document outlining procedures for scopemanagement is needed. Scope is defined and redefined constantly in agile , aspart of the planning meetings in particular, release planning and iterationplanning and by the Management of the product backlog. Remember,resources and time are typically fixed in agile approaches, and it s the scopethat is allowed to change. However, when fixed- Scope projects are required,it is the number of iterations that will change, in order to accommodate theneed for a full feature set prior to release. Additionally, one of the success cri-teria 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 respondto change.

4 The success criteria in agile thus changes to Are we providingvalue to our customer? The primary measure of progress is working 4/18/08 3:13 PM Page 68 Table 5-1 provides a summary comparison of Scope planning from thetraditional and agile perspectives. In agile projects, Scope planning isreferred to as managing the product backlog. Table 5-1 Scope PlanningTraditionalAgilePrepare a Project Scope ManagementCommit to following the framework as Plan in the chosen agile DefinitionThePMBOK Guidepractices of Scope definition, work breakdown struc-ture (WBS) creation, and Scope verification occur iteratively in agile . A tra-ditional WBS for software projects is usually divided at its highest level intophases of analysis, design, coding, testing, and deployment activities.

5 Eachof these phases is then decomposed into tasks or groups of tasks, referred toas work packages in the PMBOK Guide. Traditional project planningbegins top-down and relies on the elaboration of detailed tasks with esti-mates and dependencies to drive the project schedule via use of critical pathanalysis. Even though the PMBOK Guidegoes into great detail aboutscope decomposition by way of WBS (work breakdown structure), it alsowarns that excessive decomposition can lead to nonproductive manage-ment effort, inefficient use of resources, and decreased efficiency in per-forming the work. 2In agile , we approach these practices differently in that we define fea-tures at a high level in the product backlog and then place features into iter-ations during release planning .

6 One can think of the iteration or even thefeature itself as the agile equivalent of work packages. The features areestimated at a gross level in the product backlog no detailed tasks orresources are defined at this point in time. Once the iteration begins, the fea-tures slated for that iteration and only that iteration are then elaboratedinto tasks that represent a development plan for the feature. Think of it asjust-in-time elaboration, preventing a wasteful buildup of requirementsinventory that may never be processed. The PMBOK Guidesupports thisidea of rolling wave planning :3As the work is decomposed to lower levels 69 Scope 4/18/08 3:13 PM Page 69of detail, the ability to plan, manage, and control the work is enhancedbecause the short timeframe of the iteration reduces the amount of detailand the complexity of estimating .

7 The agile approach assumes that becausethings change so often, you shouldn t spend the time doing excessivedecomposition until you re ready to do the s look at how Scope is defined throughout an agile project by exam-ining five levels of planning common to most agile projects: the productvision, the product roadmap, the release plan, the iteration plan, and thedaily VisionAt the outset of a project, it is typical to hold a kickoff meeting. agile is nodifferent; however, the way the agile vision meeting is conducted is unlikewhat a traditional project manager might be accustomed to. Although thevision is defined and presented by the customer or business representative,it is the team that clarifies the vision during the discussions and subsequentexercises.

8 Therefore, the team is heavily involved, and group exercises are abig part of determining the final outcomes. See Chapter 4, IntegrationManagement, for more detail on vision vision meeting is designed to present the big picture, get all teammembers on the same page, and ensure a clear understanding of what it isthat they ve been brought together to do. The vision defines the mission ofthe project team and the boundaries within which they will work to achievethe desired results. The project s goal should be directly traceable to a cor-porate strategic the Scope is defined at a very high level. It is not uncommon toleave the vision meeting with only a dozen or so features identified, such as provide online order capabilities, enable international ordering anddelivery, create data warehouse of customer orders to use for marketingpurposes, and integrate with our current brick-and-mortar inventory sys-tem.

9 Clearly these are all very large pieces of functionality with little-to-nodetail and this is what is appropriate at this stage of the project. The far-ther away the delivery date, the broader the stroke given to feature RoadmapA product roadmap shows how the product will evolve over the next threeto four releases or some period of calendar time, typically quarters. The 70 Scope 4/18/08 3:13 PM Page 70product roadmap is a high-level represen-tation of what features or themes are to bedelivered in each release, the customertargeted, the architecture needed to sup-port the features, and the business valuethe release is expected to meet. The cus-tomer or product manager, agile projectmanager, architect, and executive man-agement should meet on average two tothree times a year to collaborate on thedevelopment and revision of the productroadmap.

10 Figure 5-2 shows a sample roadmap template made popular byLuke Hohmann in his book Beyond Software 71 Scope PLANNINGNoteIn agile , the word release doesnot solely mean a product releaseto the end customer it can alsomean an internal release to fulfillintegration milestones and con-tinue to confirm that the product is potentially shippable. Figure 5-2 Product roadmaptemplate, courtesy ofEnthiosys and LukeHohmann, from hisbook Beyond Soft-ware ArchitectureMarket Map(Target MarketDemographics)Time Horizon -- Quarters work MapTechnology/ArchitectureRoadmapMarket Events /RhythmsBiometricIDCOMDEX?Whattechnology should we use?SmallOfficeManagedServiceLinuxBecaus e the customer is responsible for maintaining and prioritizing thebacklog of work, the customer also owns the product roadmap.