How do unknown-scope projects achieve project-level estimation with regards to the CMMI's Project Planning Specific Goal?

Question

Specific Goal (SG) 1 of the Project Planning process area in CMMI (assessed at CMMI Level 2) is to establish estimates. One of the Specific Practices (SPs) that is recommended to achieve this goal is to estimate the scope of the project. In all of the CMMI literature that I have access to, it explicitly calls out the creation and maintenance of a work breakdown structure (WBS) to achieve this goal. However, not all projects have a clearly defined scope at the outset, making the creation of a WBS (or any type of project-level estimation) difficult. I'm aware that the CMMI is a process framework that's designed to be tailored, but the frequent and explicit mentions of the use of a WBS, rather than the use of example tools, to achieve this goal is rather confusing.

The use of a WBS, specifically the 100% rule, appears to me to be difficult to achieve in many such environments:

The 100% rule states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management.

Agile methodologies are best suited to this situations, when the project requirements or scope are not well understood. If you don't fully understand the requirements and/or scope, it's not possible to create a 100% complete WBS for the entire project scope. A WBS is better suited in a plan-driven project where the requirements are less volatile and the scope of the project is well defined.

One possible option would be to create and continually refine the WBS to accurately reflect the current understanding of the project, that seems to go against the principles of agile/lean documentation. In terms of the overall process, the existance of the WBS adds no value to the development team and producing and modifying it is wasteful. Another option might be to create a WBS on a per-iteration basis (especially if the iterations are longer), but this would be capturing the same information that might be captured in the form of the product backlog, stories, use cases, and just reformatted to "check the box" of having a WBS, which again doesn't seem very agile/lean.

I found one academic paper (PDF) that appears to suggest that the appropriate mapping from Scrum to this process area is to indeed create a WBS at the beginning of each sprint. However, some aspects of this paper make me question if the authors have a good grasp of Scrum as a project management framework. For example, the authors write

There are not explicit orientations in SCRUM to establish, for instance, size and/or complexity of items of Product Backlog and Sprint Backlog.

This is true, however individual teams generally develop a consistent process for determining these values. For example, a common method is using Planning Poker to determine the Story Points associated with each User Story in the backlog. The Scrum framework allows teams to choose what works for them, and encourages consistency when peforming such a task.

There are also a few other instances of similar questionable statements.

I'm well aware that the identified Specific Practices (SPs) in CMMI are a model for organizations to follow. An organization can develop their own practices, as long as they meet the Specific Goal (SG) of the area. Many of the SPs are written to be along the lines of "best practices" for projects, process, quality, and continuous improvement and can be applied to any project. In addition, the SPs provide examples of tools, techniques, and methodologies that might be used to carry out the practice to achieve the goal. However, SP 1.1 (Estimate the Scope of the Project) is something that can't (easily) be done on a number of projects with vague scope, yet must be addressed somehow to achieve/maintain CMMI Level 2.

What techniques have organizations used to achieve this goal on projects with a poorly-defined scope in a manner acceptable within the CMMI framework and reach or surpass CMMI Level 2? Are there any issues with introducing alternative means of producing estimates during an audit? What feedback has been provided by the SEI or CMMI auditors to companies regarding what should be done regarding projects with vague scope? Is this a practice that can simply be neglected in projects that are difficult to estimate as a whole unit, as long as the specific goals of establishing estimates for work and tasks, defining life cycles, and smaller scale cost/effort estimations are maintained?

Answer 1

The items in the WBS should be thought of as control accounts. It is common practice to create an estimate based on the level of information available at the time. Then, as more information is learned, to progressively elaborate/decompose the control account into finer levels of detail, refining the estimates along the way.

Unknowns can be accounted for in the risk register and reserve accounts. These are refined, as well, as more information becomes available over time.

Both of these processes can be well documented and create artifacts that support CMMI.

Answer 2

The Project Management process area is clearly focused on waterfall methodologies. It doesn't apply to Agile projects as stated. Feel free to ignore it. Or better, modify it.

Don't try to specify the broad, vague overall scope. It doesn't work well, because it ignores the Agile principle of delivering value. The PP area shifts focus from value to schedule (something the user's have no interest in.)

If you shift PP to be Sprint Planning you'll be a whole lot happier.

One of the most important lessons learned over the last few decades is that all projects change their scope. That change in scope can be labeled as a "failure to meet the original scope" or "a change in scope that emphasizes delivering value."

I'm not sure how reliable this is, as I disagree with some of their conclusions

"Reliable"? That doesn't make much sense. Explain.

Please identify the specific conclusions you don't agree with, otherwise, there's no possible answer to this question.

What techniques have agile organizations used to achieve this goal and reach CMMI Level 2 (or greater)?

Focus on sprints and backlogs instead of some vague and hard-to-define overall scope.

Are there any issues with introducing alternative means of producting estimates during an audit?

No.

Answer 3

I believe Agile development is perfectly compatible CMMI. What is key to properly define the "project". If you define the current project to be the current sprint rather than the "total project" you have no problem. According to wikipedia:

Sprint

A sprint is the basic unit of development in Scrum. Sprints tend to last between one week and one month,[6] and are a "timeboxed" (i.e. restricted to a specific duration) effort of a constant length.[8]

Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting,[9] where the progress is reviewed and lessons for the next sprint are identified.

Think of it like going out to dinner and the waiter taking your order. When you start you may have a good idea that you will have a drink followed by an appetizer, main course and desert. When the waiter takes your drink order you probably have no idea what you want for desert, or even if you will skip desert. This does not in any impact the waiters ability to execute a "plan" to bring you your drink.

At this level a WBS and project plan is easy.

Answer 4

Funny you ask this because this is something that we discussed in PM training the other day. My instructor didn't have a satisfying answer for me, but mostly because his background didn't involve project management of Agile projects.

My take on this is that the WBS really doesn't have a place in Agile, but that doesn't necessarily mean that it is not important. You are right that it shouldn't mean anything to developers, but it should help define the initial project estimates which is important for management to know.

Many Agile projects operate in the realms of a fixed deadline, (fixed scope?) arena where sprint releases to clients are still important, but merely from an evaulation or testing perspective on their end. The contract is signed, they already have a ROUGH idea about what they want delivered, and when they want it. Requirements can and do change, but the high level deliverables tend to stay the same, as they are usually detailed out in the contract. The WBS can play an important role of summarizing all the high level deliverables as described in the contract, and can form the basis for the original set of user stories.