A previous H&A blog, “EVM (Earned Value Management) vs. Agile Project Management,” provided an introduction to the differences between an Earned Value Management System (EVMS) and Agile development methodologies.
At first glance, it may seem that EVM and Agile development methodologies are incompatible. Agile is all about rapid incremental product deliveries and responding quickly to an evolving understanding of the desired deliverable or outcome. Depending on how an EVMS is implemented, the EVMS can often seem rigid in comparison.
Can the two methodologies coexist and complement each other to create an effective integrated project management system? The answer is yes, provided you have thought through how you intend to use the two systems together and map how and where they integrate. The goal is to leverage the benefits of each system and without forcing either system to do something it wasn’t meant to do.
There is a natural top down and bottom-up process integration when defining the scope of work and acceptance criteria. This process integration continues for planning and scheduling the feature estimates of effort, establishing the budget baseline, and ultimately maintaining the estimate to complete (ETC) in the EVMS. It also supports an integrated process for measuring completed work. The Agile daily standup meetings provide current information about accomplishments and impediments at the lowest level of the project. The Agile system provides the quantifiable backup data for claiming earned value in the EVMS for performance reporting.
The following image illustrates the relationship between the two systems.
The Foundation for Integrating EVM and Agile: Defining the Scope of Work
A work breakdown structure (WBS) is commonly used to organize and decompose a project’s scope of work into manageable, product-oriented elements. It is an essential communication tool for the customer and contractor so they have a common frame of reference to capture and manage requirements as well as expected deliverables or outcomes. It establishes a common basis for measuring progress and defining accomplishment criteria. It is the framework for developing a project’s schedule (timing of tasks), identifying resources to accomplish the scheduled tasks, creating cost estimates as well as the budget baseline, and identifying risks. In an EVMS, the WBS is often decomposed to the control account level which is further decomposed into work packages or planning packages. Once extended to the lower level, it provides a framework for tracking technical accomplishments, measuring completed work, and identifying variances from the original plan to complete the work.
There is a similar planning hierarchy to Agile projects – the Product Backlog is the foundation for defining the scope of work. The Product Backlog starts at the Epic or Capability level and is further defined through product planning. The process includes prioritizing the capabilities and defining the sequence of deliverables to create the Product Roadmap (timing). The capabilities are decomposed into features along with an estimate of the effort to deliver the feature. Features should include exit criteria (definition of done) and have minimal dependencies. At the lowest level, features are decomposed into Sprint Stories and related tasks forming the basis for the schedule and measuring completed work in the EVMS. As illustrated in the image above, in the Product Backlog hierarchy, an Epic/Capability relates to the control account level in the EVMS. Features relate to the work packages in the EVMS.
In an integrated environment, there can be a natural mapping between the WBS and the Product Backlog regardless of the starting point. When starting from the Agile system, the Product Backlog could be used to create the project’s WBS. The customer may also pre-define the top level WBS elements that could form the backlog structure. The DoD uses MIL-STD-881, Work Breakdown Structures for Defense Materiel Items, for this purpose so they have a set of common templates they can use across programs to capture historical actual cost data for cost estimating and should cost analysis. Even though the top level WBS elements may be pre-defined, the lower-level content can reflect an outcome based Agile structure that focuses on customer driven deliverables.
An example is illustrated here.
What’s common between the two systems? You have:
- Decomposed a common understanding of the scope of work into manageable, product or outcome-oriented elements of work.
- Defined the agreed upon accomplishment criteria or definition of done for a given deliverable or outcome.
- Built a framework to determine the timing of tasks, identifying the resource requirements, creating a cost estimate to do the work, and means to objectively measure completed work. Ideally, you have also identified the risks or uncertainties so you know where potential issues may surface.
Best Practices for Integrating the WBS and Product Backlog
Keeping in mind you have a similar decomposition of work between the two systems, you can set up the WBS and Product Backlog to align with each other. The goal is to ensure traceability so you can easily support the EVMS requirements.
Here are a few best practices for integrating the WBS and Product Backlog.
- Verify the WBS aligns with the prioritized Product Backlog to at least the Epic/Capability level (control account level in the WBS). Determine how you intend to maintain traceability between the WBS elements and the work items in the Product Backlog so it doesn’t matter which system you use to review or confirm the agreed upon scope of work. Identify and document how you intend to map the WBS elements to a work item in the Product Backlog so you always have the necessary cross references identified. Keep it simple. Where possible, minimize the need to enter something more than once.
- Use the Product Backlog to tailor the WBS. This is particularly true for projects where Agile development is central to the final deliverable. Consider your two end objectives: you need to provide project performance reporting via the EVMS and organize the items in the Product Backlog so you can decompose them from the Epic/Capability level to the Feature level and then to the Sprint Story and task level.
- Watch the level of detail in the WBS. Avoid driving the WBS to too low a level of detail. Depending on the project, it may be appropriate to go no lower than the Epic/Capability level (control account level). The reasoning: in the Agile system, the lower-level Stories and tasks are flexible and subject to change. You are focused on completing current near-term work effort within a Sprint. Better to let the Agile system manage and track what is happening at the rapidly changing detail level – it is designed to do that. For EVMS purposes, project monitoring and control should be at a higher level where scope can be consistently defined, aligned to the schedule and budget, and claimed as done (technical accomplishment). The WBS should reflect the level of detail that is aligned to the permissible variation in requirements or configuration. Otherwise, you create too much change “noise” in the EVMS.
- Confirm the WBS and Product Backlog contains 100% of the contract scope of work. Verify the statement of work has been mapped to the WBS elements or work items in the Product Backlog. Why is this important? You need to demonstrate you have captured the entire technical scope of work to at least the Epic/Capability level. You need this for internal planning purposes so your development teams have an understanding of the technical requirements and expected outcomes as well as managing changes. Your customer also needs confidence that you have an understanding of the entire scope of work and have planned accordingly for the duration of the project.
- Verify you have defined the Feature accomplishment criteria or definition of done so it is easy to measure completed work. This could be in the WBS dictionary or documented in the Agile system Product Backlog. Determine where that information can be found and document the process to maintain it. Ideally it is in one place so you only have to maintain it in one system and everyone on the project knows they are referencing current information. Clearly defined accomplishment criteria mean you can objectively measure accomplishments – in both systems. Enable that capability right from the start when you set up a new project in the two systems.
Are your EVM and Agile systems are sharing useful information? Perhaps you have learned the hard way the WBS and Product Backlog aren’t sufficiently mapped for you to maintain traceability between the two systems. We can help. Call us today at (714) 685-1730