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?