6

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?

  • is 100% rule formally specified as mandatory to certify at CMMI Level 2? also, what version CMMI do you refer to? wikipedia says that in the CMMI V1.3, "agile has been included with an interpretation guideline and by adding notes to the applicable process areas in the introduction of the process area and on how to interpret agile practices." – gnat Dec 22 '11 at 13:56
  • @gnat I'm not sure if the 100% rule is required, but I assume it is since it's part of the definition of a WBS. From CMMI Distilled (which covers CMMI 1.2, the last version of CMMI): "...the scope of the project is estimated based on a work breakdown structure, and project attributes for work products and tasks are estimated." Given that a WBS must include 100% of a project and the project is to be estimated using a WBS, it appears that the 100% rule is required. – Thomas Owens Dec 22 '11 at 13:59
  • @gnat As far as CMMI 1.3, I have yet to find the notes and guidelines that you are referring to. I suspect the answer to my question would be in those notes and guidelines, but without access to them, I don't have an answer on my own. If you are able to cite the text of those notes with respect to Project Planning and Estimation, I would probably accept that as the definitive answer. – Thomas Owens Dec 22 '11 at 14:01
  • @ThomasOwens I see. The way you derive CMMI dependency on WBS makes perfect sense to me. If that's the case and if wikipedia wording is accurate, then deviation from 100%-rule doesn't look like certification blocker to me. Thing is, 100%-rule is stated as design principle - wording like that is typically insufficient to justify incompliance (as opposed to eg mandatory attribute or must type requirement). With this in mind I'd rather say your assumption that WBS must include 100% of a project looks questionable to me - at least until one sticks with design principle definition. – gnat Dec 22 '11 at 14:17
  • 2
    I see your point about Agile being nearly exlusive to software development. Regardless it is flagged so a higher order mod can figure out what to do with it from here. On the other note, your question raises some concerns to me about the legitimacy of CMMI in regards to Agile and I am curious if the SEI has made any statements regarding its stance on Agile project management methodologies. If the SEI considers Agile, then I personally don't see the lack of a WBS as grounds for incompliance as being justified. – maple_shaft Dec 22 '11 at 16:00
2

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.

1

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.

  • Only this one SP seems to be plan-centric, unlike the others in the Project Planning process area as well as most of the other process areas. The others are generic enough to apply to both agile and plan-driven methodologies, even in the text regarding CMMI 1.3, which accounts for agile methodologies. Ignoring this practice outright would be risking CMMI Level 2, and it doesn't leave much room the way its written for modification (although CMMI is supposed to be a framework, and many other practices lend themselves well to modification and interpretation). – Thomas Owens Dec 22 '11 at 14:17
  • As far as specific conclusions in the paper I don't agree with, that's beyond the scope of this question. But one is that Scrum doesn't satisfy SP 1.2 Establish Estimates of Work Product and Task Attributes. The authors assert that this is because Scrum doesn't explicitly call for size measures, but that's because Scrum is a process framework that is meant to be tailored. Scrum clearly calls for a team to identify a size measure (often, but not always, Story Points) and a method to compute them (often, but not always, Planning Poker). By implementing Scrum, you implement this CMMI requirement. – Thomas Owens Dec 22 '11 at 14:20
  • Can you also expand on your "no"? Did you go through a CMMI audit in an agile organization? What did your organization do to achieve the requirements of this process area? What were the comments presented by the auditors in their close-out review session? – Thomas Owens Dec 22 '11 at 14:21
  • 1
    @ThomasOwens: "alternative means of producting estimates" can mean anything. You're not talking about "estimates". You're talking about "project scope" which is a slightly different thing. If your Defined or Managed process is Scrum where backlog == scope, backlog story points == overall estimate, and sprint story points == sprint estimate, you seem to be covered. Don't ask me for audit input; I'm not your auditor. Ask your auditor. If they expect to see waterfall, Agile will fail. If they expect to see Managed, Agile will pass. – S.Lott Dec 22 '11 at 15:14
  • 1
    "do I address this issue before it becomes a problem?" You are addressing the issue before it becomes a problem. "Did you go through a CMMI audit in an agile organization?" is irrelevant to your organization and your audit. Since you have no audit, you're doing the right thing. When you have an audit, you may need to change. Do you get what Agile means? Solve one small problem now. Don't anticipate future problems which do not yet exist. – S.Lott Dec 22 '11 at 16:20
1

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.

  • This really doesn't address my question. I'm not asking about how to plan and manage projects, but what impacts exist on a unknown-scope project under CMMI. Agile is compatible with CMMI - it's been well documented by the SEI. However, my questions aren't about managing the project. Is presenting an iteration as a "project" sufficient to auditors? How much high-level project planning documentation is required and how much can be shifted into iteration planning? For people who have undergone a CMMI review with such a project, what did you do and what was the response of the auditors? – Thomas Owens Dec 23 '11 at 14:35
  • Thomas: I believe the key is proper definition of "project". If you define a project "Find a cure for cancer" you will have a problem. If you define a project "We will employ 10 scientists this year to do cancer research" then you have a classical project. Now the "employ 10" project may be the first step towards the larger goal, and second year funding and planning may be contingent on what happens the first year, but that is not part of the first year project. – JonnyBoats Dec 23 '11 at 15:15
  • Thomas: Relative to the auditors, passing at level 2 should be rather easy compared to level 5 for example. I use to work for a large firm where we had various divisions all over the map (including level 5) in terms of maturity. Are your particular auditors perhaps being overly picky or perhaps misunderstanding something? – JonnyBoats Dec 23 '11 at 15:19
  • There are no auditors, there are is project. As a general rule, the CMMI is fairly general in terms of practices and how you go about implementing them in a manner appropriate with any project management methodology, with the exception of this Specific Practice and Specific Goal. I'm trying to figure out how this impacts projects with unknown scope. – Thomas Owens Dec 23 '11 at 15:29
  • Thomas: What I am suggesting is that all projects should have a defined scope. Scope can be defined in many ways, including time and materials. So defining the project as 3 programmers will work for 8 weeks to try and come up with some sort of Facebook game (or whatever) is fine. Saying an indeterminate number of people will work for as long as they want and spend as much as they want doing whatever they want is not OK. The deliverables do not need to be fixed, but in the absence of fixed deliverables the level of effort and duration should be. – JonnyBoats Dec 23 '11 at 16:31
0

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.

  • 1
    I agree that you can create a WBS and get value from it in a fixed-scope project. I agree that iterative releases are still valuable. But the strength of agile is in projects where scope is vague and requirements are unclear. In such a case, work packages can be added and removed from the WBS in the middle of a project, between iterations. It just seems like wasted effort to create a WBS in that type of environment. The known work packages would be at such a high level that I just don't see the value in creating that praticular artifact. – Thomas Owens Dec 22 '11 at 14:07
  • 1
    I guess my concern is that if you can't add menaingful granularity to the WBS, why create one? In my experiences, other documents capture the high level deliverables and the value of a WBS is outlining the work that needs to be done to create those deliverables. If you don't necessarily know exactly what you need to do to create the high level deliverables, the WBS adds so little value that it's not worth the time to create. – Thomas Owens Dec 22 '11 at 14:09
  • "why create one?" Precisely. There's no real value, since it will be updated at the end of the sprint. The backlog has been shown to be adequate. – S.Lott Dec 22 '11 at 14:10
  • @S.Lott But would a backlog be acceptable to a CMMI auditor? If all of the CMMI books and articles that I can come across specifically mention that a WBS is used to estimate scope, what would an auditor's reaction be to an organization that does not produce a WBS? I can't find any accounts of an audit where the development organization was using agile and what the auditor(s) found with regards to project planning without a WBS. – Thomas Owens Dec 22 '11 at 14:25
  • @ThomasOwens WBS adds so little value that it's not worth the time to create. You may be perhaps right, however a WBS was never anything that I slaved over for any meaningful amount of time. It has never taken me more than an hour to type one up assuming that I have all my notes available to me, and a document template to work off of. If it is something that CMMI auditors hold in high regards then it is either something that you create just for them to see, or as an organization you may have to evaluate whether your organizations approach to project management should even align to CMMI. – maple_shaft Dec 22 '11 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.