What is mandatory to have about a WBS? What must a top-level WBS contain?

The CMMI defines Work Breakdown Structure (WBS) as an arrangement of work elements and their relationship to each other and to the end product. What this definition means is that the WBS is a basically a list of all of the tasks that must be performed from the start of the project to the conclusion of the project. So typically the WBS includes the tasks associated with:

1. Managing the project
2. Managing the configuration(s) and configuration items
3. Managing the requirements
4. Managing the software engineering activities of requirements engineering, design, development, test, build, and delivery
5. Managing the suppliers, if there are any
6. And perhaps others that I may have overlooked

This list of tasks/activities applies to any type of development from the legacy waterfall to Agile. Just the specific details will differ. Now WBS only appears in four locations in the CMMI-DEV: PP, PMC, IPM, and RSKM.

PP SP 1.1 addresses the top-level WBS that you use to estimate the scope of the project. The intent of this practice is not to develop a detailed WBS at this point, but to start with a somewhat “generic”, for the lack of a better term, WBS that applies to all similar projects in the organization that the Project Manager can use to structure his or her initial estimation efforts. Then over the life of the project, as the PM and team gain knowledge about the project, the WBS becomes more detailed. In some organizations, there is confusion about the term WBS because if the organization is under contract to a customer, the contract may include a WBS. Depending on the size and scope of the project, the contract WBS may not be the same as the WBS for the project.

PMC Introductory Notes refers to the WBS in the context of tracking project progress per the project schedule or WBS.

IPM SP 1.4 sub-practice 7 refers to the WBS in the context of having very tight control of the initiation and completion of the tasks described in the WBS.

RSKM SP 2.1 Hint refers to the WBS as a source for identifying risks.

So the bottom line, is that the most guidance the CMMI gives for the WBS is in PP. There are no specific requirements for what a top-level WBS must contain. What you should do is structure the WBS based on the product architecture, application domain, and methodology. To keep the WBS at the right level, identify groups of related activities that are usually performed together. Each activity group should be defined in sufficient detail so it can be reasonably estimated, have responsibilities assigned, and placed on the project schedule. And finally each activity group should have its outputs/work products clearly defined. If you cannot define one or more work products for an activity group, then you probably have not grouped the activities correctly. And as you grow in knowledge and maturity in using the WBS, you may evolve your WBS so that the tasks and activities it contains are networked (predecessor/successor relationships) to enable critical path analysis.