How Scrum helps with CMMI
For organizations that use CMMI for process improvement, Scrum provides lean and professional solutions for the management of complex projects. This article describes how you can use both CMMI and Scrum together, and how both benefit from each other.
How Scrum and CMMI fit together
CMMI is a collection of good practices that are typically done by a professional development organization. CMMI describes "what" to do. Every organization establishes its own way of "how" to do it. Identifying your own way of work that fits your organization's culture is one of the key points of CMMI. Why? Because the way an organization works rests on the cultural principles and the business values of that organization. CMMI is a coach that asks you the right questions to facilitate you in finding solutions that fit your organization's culture and that consider all the important things.
This is how Scrum and CMMI fit perfectly together. While CMMI lists e.g. the good practices of project management, Scrum provides a concrete solution that you can apply in your project. Scrum is one of the agile frameworks and rests on agile values. Scrum is therefore a good solution for the project management practices of CMMI for organizations that apply agile values.
Scrum and CMMI enhance each other
Basically, agile values, Scrum and CMMI are an excellent complement to one another. Both overlap in their claim for discipline (Scrum) or professionalism (CMMI). Agile organizations can extend the Scrum framework beyond projects with the help of a CMMI. It supports you in establishing agile solutions e.g. for leadership. On the other hand organizations that use CMMI can establish lean techniques with Scrum. Read more in our article "Scrum and CMMI – Does it fit together?"
In this Article: Mapping of Scrum and CMMI
In this article we describe which CMMI practices are implemented by Scrum: who does it, how it is implemented, and what is the result. The article is a guide for organizations that implement Scrum as and at the same time use and appreciate the orientation of CMMI.
Requirements Management (REQM) in Scrum
Scrum implements an efficient and lean requirements management. Scrum implements all the practices you expect from professional requirements management. Even if it looks very lean from the perspective of a more "classic" project: the check with CMMI shows that all practices of requirements management (REQM) are fully implemented by Scrum.
CMMI "What" |
Scrum "How" |
Degree of Implementation |
|---|---|---|
REQM.SP 1.1 Obtain an understanding of requirements |
The Product Owner writes and prioritizes the Product Backlog items (user stories) according to their business value continuously. |
Fully |
REQM.SP 1.2 Obtain Commitment to Requirement Changes |
The Team agrees to the Selected Product Backlog (which it can commit to deliver in the next Sprint, based on the Definition of Done) in the Sprint Planning meeting. |
Fully |
REQM.SP 1.3 Manage requirements changes |
The Product Owner adds, reprioritizes or drops items (user stories) to the Product Backlog continuously. The Product Owner can also change the Definition of Done. |
Fully |
REQM.SP 1.4 Maintain bidirectional traceability |
The Product Owner maintains the Product Backlog items in a hierarchy of epics and user stories (vertical traceability). |
Fully |
REQM.SP 1.5 Identify inconsistencies between project work and requirements |
The Team presents for each Selected Product Backlog item (user story) whether the Potentially Shippable Product Increment meets the requirements according to the Definition of Done. The Product Owner reviews each item and accepts it. This is performed in the Sprint Review. |
Fully |
Project Planning (PP) in Scrum
Scrum implements most practices of project planning. Scrum provides surprisingly simple solutions. However, the simplicity is achieved by smart solutions, and not by omitting.
A good example for smart solutions is the implementation of the work breakdown structure. Scrum uses the items in the product backlog (the requirements) as the top level for planning. With this, Scrum provides a smart solution for the classic problem of project management: to keep requirements and plans in sync. The smart solution also simplifies monitoring the plans, because there is less to monitor. Moreover, the simpler solutions support the team's discipline because it is less effort to maintain things.
The comparison with CMMI shows two topics where Scrum does not provide an off-the-shelf answer. This is risk management and data management. If you think both are important (which they probably are) a Scrum team can extend the framework with little effort. In the table below we provide an example how this can be done.
There are some topics that Scrum addresses largely but not fully. E.g. Scrum provides a project plan but does not address a budget explicitly. In many cases this can be sufficient, but there are also projects where the Product Owner will request a budget or the planning of other resources (besides people) from the team. In this case Team, Product Owner and ScrumMaster should establish a solution that fits the Scrum framework and the agile values.
Estimation in Scrum
CMMI "What" |
Scrum "How" |
Degree of Implementation |
|---|---|---|
PP.SP 1.1 Estimate the Scope of the Project |
The Product Owner maintains the Product Backlog with User Stories continuously. |
Fully |
PP.SP 1.2 Establish Estimates of Work Product and Task Attributes |
The Team estimates Story Points (relative effort) for every user story in Sprint Planning or in Release Planning. |
Fully |
PP.SP 1.3 Define Project Lifecycle |
In Scrum the phases are a regular sequence of Sprints. |
Fully |
PP.SP 1.4 Determine Estimates of Effort and Cost |
The Team calculates the Team’s effort for each User Story based on the current velocity, multiplied by the Story Points (relative effort) in Sprint Planning I or in Release Planning. |
Largely |
Project Plan in Scrum
CMMI "What" |
Scrum "How" |
Degree of Implementation |
|---|---|---|
PP.SP 2.1 Establish and maintain the project’s budget and schedule. |
The Team establishes a short-term schedule in the Sprint Backlog, which contains the Selected Product Backlog and the Tasks, during Sprint Planning II. |
Largely |
PP.SP 2.2 Identify Project Risks |
The Scrum framework does not explicitly address risks. |
Not Addressed -> Fully |
PP.SP 2.3 Plan for Data Management |
The Scrum framework does not explicitly address data management. |
Not Addressed -> Fully |
PP.SP 2.4 Plan for Project Resources |
The Team decides how much User Stories can be delivered with given resources and skills in the next Sprint in Sprint Planning I. |
Largely |
PP.SP 2.5 Plan for Needed Knowledge and Skills |
In Scrum, resources with their skills, and the time, are given and the amount of work is adapted to that. Interdisciplinary teams are used so that team members can learn from each other while they do the work. |
Fully |
PP.SP 2.6 Plan Stakeholder Involvement |
In Scrum, there is general definition of three stakeholder roles and their involvement in the project (Team, Scrum Master, Product Owner). |
Largely |
PP.SP 2.7 Establish the Project Plan |
Team and Product Owner keep Sprint Backlog and Product Backlog synchronized through the Selected Product Backlog. Any task in the Sprint Backlog belongs to an item of the Selected Product Backlog, which has been taken from the Product Backlog during Sprint Planning I. |
Fully |
Commitment in Scrum
CMMI "What" |
Scrum "How" |
Degree of Implementation |
|---|---|---|
PP.SP 3.1 Review Plans That Affect the Project |
In case of one single team, Product Owner and Team maintain all requirements in one single Product Backlog and one single Sprint Backlog. |
Fully |
PP.SP 3.2 Reconcile Work and Resource Levels |
The Team balances work and resources by only committing to those items of the Product Backlog, which it can deliver during the next Sprint. |
Largely |
PP.SP 3.3 Obtain Plan Commitment |
The Team commits to deliver the User Stories of the Selected Product Backlog in Sprint Planning I. |
Fully |
Project Monitoring and Control (PMC) in Scrum
Project monitoring is one of the clear strengths of Scrum. Doing the work and identifying issues as early as possible ("inspect and adapt") is one of the key principles of Scrum. The team monitors the Sprint Backlog and the Impediment Backlog in the Daily Scrum. The Sprint Burndown chart further supports monitoring. The results of a Sprint are reviewed in the Sprint Review, and the way of work is reviewed in the Sprint Retrospective. Impediments are recorded in the impediment backlog and tracked to closure by the Scrum Master. Scrum rigorously implements the "Plan-Do-Check-Act" cycle that CMMI suggests as a good practice.
However, Scrum does not address risk and data management, neither in planning nor in monitoring. However, if the Scrum framework is extended with little effort to include risk or data management, the normal monitoring mechanisms also work for risks and data.
Monitoring of the Plan in Scrum
CMMI "What" |
Scrum "How" |
Degree of Implementation |
|---|---|---|
PMC.SP 1.1 Monitor Project Planning Parameters |
The Team maintains the Sprint Backlog and the Sprint Burndown daily. |
Fully |
PMC.SP 1.2 Monitor Commitments |
The Team monitors the commitment of the team members during Daily Standup. |
Fully |
PMC.SP 1.3 Monitor Project Risks |
The Scrum framework does not explicitly address risks. |
Not Addressed -> Fully |
PMC.SP 1.4 Monitor Data Management |
The Scrum framework does not explicitly address data management. |
Not Addressed -> Fully |
PMC.SP 1.5 Monitor Stakeholder Involvement |
The Team monitors the commitment of the team members during Daily Standup. |
Fully |
PMC.SP 1.6 Conduct Progress Reviews |
The Team monitors the progress of the work during Daily Standup. |
Fully |
PMC.SP 1.7 Conduct Milestone Reviews |
The Team and the Product Owner review the Potentially Shippable Product during the Sprint Review. |
Fully |
Manage Corrective Actions in Scrum
CMMI "What" |
Scrum "How" |
Degree of Implementation |
|---|---|---|
PMC.SP 2.1 Analyze Issues |
Team, Product Owner and ScrumMaster identify issues (in Scrum they are called “impediments”) during Daily Standup, Sprint Review and Sprint Retrospective. |
Fully |
PMC.SP 2.2 Take corrective action |
The ScrumMaster maintains the Impediments in the Impediment Backlog. The ScrumMaster takes the necessary actions to remove the impediments throughout the Sprint. |
Fully |
SP 2.3 Manage corrective actions to closure. |
The ScrumMaster tracks the Impediments in the Impediment Backlog. |
Fully |
Why use both Scrum and CMMI?
This article shows that Scrum provides lean but nevertheless complete solutions for all the topics that professional requirements and project management requires. The particular charm lies in the smart solutions and in the feasibility of the planning and monitoring solutions. We also showed the value that lies in CMMI: the check showed us two topics that are not addressed in off-the-shelf Scrum implementations, and thus we came up with two extensions of the Scrum framework that address risk and data management with little extensions that cause minor effort – if at all.
About the Authors
David Croome and Malte Foegen use Scrum for the management of projects since several years. They know Scrum from every day project work. Malte Foegen is also SEI Certified Lead Appraiser. David Croome and Malte Foegen have come to love both Scrum and CMMI, because they have seen which value both can bring to organizations if they are used properly and with professional knowledge. With this article they provide guidance for users who want to use agile solutions in a CMMI environment how to use both. This article shows also that Scrum must be implemented fully and properly to take effect.
More Articles about Scrum and CMMI

RSS Feed
