Mapping CMMI Project Management Process Areas to SCRUM Practices

Ana Sofia C. Marçal1,2, Bruno Celso C. de Freitas2, Felipe S. Furtado Soares2, Arnaldo D.
Belchior1
1
University of Fortaleza - Master's Degree in Applied Computer Science
Av. Washington Soares 1321, 60811-341, Fortaleza - CE, Brazil
2
C.E.S.A.R - Recife Center of Advanced Systems and Studies
Rua Bione, nº 220, Cais do Apolo 50.0303-90, Recife - PE, Brazil
{ana.sofia, bruno.freitas, felipe.furtado}@cesar.org.br, [email protected]

Abstract According to Boehm [4], so far, this decade has

seen a continuation in the trend toward rapid
Over the past years, the Capability Maturity Model application development and an acceleration of the
(CMM) and Capability Maturity Model Integration pace of change in information technology, in
(CMMI) have been broadly used for assessing organizations, in competitive countermeasures, and
organizational maturity and process capability also in the environment. This rapid change of pace has
throughout the world [20]. However, the rapid pace of caused increasing frustration to the heavyweight plans,
change in information technology has caused specifications, and other documentation imposed by
increasing frustration to the heavyweight plans, contractual inertia and maturity model compliance
specifications, and other documentation imposed by criteria. He continues saying that the late 1990’s saw
contractual inertia and maturity model compliance the emergence of a number of agile methods such as
criteria [4]. In light of that, agile methodologies have Adaptive Software Development, Crystal, Dynamic
been adopted to tackle this challenge. The aim of our Systems Development, eXtreme Programming (XP),
paper is to present mapping between CMMI and one of Feature Driven Development, and Scrum. All of these
these methodologies, Scrum. It shows how Scrum methods employ agile principles, such as iterative
addresses the Project Management Process Areas of cycles, early delivery of working software and
CMMI. This is useful for organizations that have their simplicity as defined in AgileManifesto [3] published
plan-driven process based on the CMMI model and are in 2001.
planning to improve its processes toward agility or to Scrum has attracted significant attention amongst
help organizations to define a new project software practitioners during last five years. Whereas
management framework based on both CMMI and the Extreme Programming method, which has been
Scrum practices. widely accepted as one of the most important agile
approaches, has a definite programming flavor, Scrum
1. Introduction concentrates on managing software projects.
CMM or CMMI and other agile methods have been
Over the past years, the Capability Maturity Model compared in several studies, and mappings or
(CMM) and Capability Maturity Model Integration comparisons between agile and CMMI practices have
(CMMI) have been broadly used for assessing been proposed [2], [11], [14], [15], [19]. For example,
organizational maturity and process capability Paulk [15] suggests that XP’s use of stories, on site
throughout the world [20]. customer and continuous integration fulfill the SW-
Organizations are tending to adopt the CMMI CMM requirement management goals. On the other
framework because improvement in software quality hand, Turner and Jain [19] found in their study that
has been associated with higher levels of CMMI several of the CMMI components and agile methods
compliance [7], [8]. These improvements include: were in conflict, most of them being those addressing
reduced rework, predictable engineering and organizational processes. Pikkarainen and Mäntyniemi
milestones, measurable improvements in products and [16] conclude that many of them were also found to be
services and greater customer satisfaction [1]. supportive or neutral to each other, especially those
focusing on project management.
 In this context of Project Management, what can we group of related activities performed collectively to
say about Scrum’s alignment with CMMI? Can they achieve a set of goals. In the context of these models,
co-exist? How agile project management used with processes refer to "what to do" rather than "how to do
Scrum is compliant to the CMMI goals and practices? it." A process area specifies goals that describe the
The aim of our paper is to present mapping between result of successful application and practices that
CMMI and Scrum practices, showing how Scrum describe required (and expected) activities to achieve
addresses the Project Management Process Areas of those goals. Some goals and practices are specific to
CMMI. This is useful for organizations that have their the process area; others are generic and apply across all
plan-driven process based on CMMI model and are process areas. These generics describe essential ways
planning to improve its processes toward agility or to in which a process can be institutionalized.
help organizations to define a new project management Institutionalization refers to a process's degree of
framework based on both CMMI and Scrum practices. repeatability, standardization, and sophistication of
The paper is divided as follows: Section 2 presents control. Process areas can be grouped into four
the background overview of CMMI and the Scrum; categories: Process Management, Project Management,
Section 3 focuses on describing the methodology used Engineering and Support.
to do the mapping between CMMI Project
Management Process Areas and Scrum practices, 2.2. Scrum
showing the rating, gaps and the strengths between
them and the results from the overall mapping; The last Agile methods define how the work should be
section concludes the paper with final remarks. carried out under agile values and principles to answer
the challenges of rapid development and changing
2. Background Overview requirements. Agility, as characterized by Highsmith
[9], is the ability of both creating and responding to
2.1. CMMI change in order to profit in a turbulent business
environment.
According to SEI, CMMI (Capability Maturity Ken Schwaber first described Scrum in 1996 [18] as
Model Integration) is a process improvement maturity a process that accepts that the development process is
model for the development of products and services. It unpredictable, formalizing the “do what it takes”
consists of best practices that address development and mentality, and has found success with numerous
maintenance activities that cover the product lifecycle independent software vendors. The term is borrowed
from conception through delivery and maintenance [5]. from Rugby: “[A] Scrum occurs when players from
CMMI is available in two representations: staged or each team huddle closely together . . . in an attempt to
continuous. Each representation organizes process advance down the playing field” [10].
areas and the application of the generics to them According to Schwaber [17], Scrum starts with the
differently. These two representations are really just premise that software development is too complex and
different views of the same content. A staged unpredictable to be planned exactly in advance.
representation may be said to focus on the Instead, empirical process control must be applied to
organization's processes as a whole, to provide a ensure visibility, inspection, and adaptation. The
roadmap for process improvement with proven different environmental and technical variables (such
predefined groupings of process areas, and to provide as time frame, quality, requirements, resources,
an easy migration path from the SW-CMM. A implementation technologies and tools, and even
continuous representation may be said to focus on development methods) must be controlled constantly in
improvement to individual process areas chosen to order to be able to adapt to changes flexibly. This is
align with specific organizational needs and to provide achieved through an iterative and incremental
an easy migration path from Electronic Industries development process.
Alliance Interim Standard (EIA/IS) 731 [13]. Scrum implements an iterative, incremental
The continuous representation groups process areas skeleton through three roles: the Product Owner, the
by affinity categories and designates capability levels Team, and the ScrumMaster [17], as shown in Table 1.
for process improvement within each process area. The A detailed Scrum flow is shown in Figure 1.
staged representation organizes process areas into five According to Schwaber [17], a SCRUM-based project
maturity levels to support and guide process starts from a high-level vision of the system to be
improvement. developed. After that, Product Backlog is created
CMMI for Development (CMMI-DEV) [5], Version containing a list of known requirements. So, the items
1.2, describes 22 process areas. A process area is a
of the Product Backlog are prioritized and divided into What have you done on this project since the last Daily
small time-boxed iterations (called sprints). Scrum Meeting? What will you do before the next
Every task in SCRUM is carried out through meeting? Do you have any obstacles? At the end of
Sprints. A Sprint is a 30-day period of development each sprint, the team presents its results to the
time. Schwaber [17] explains that each Sprint is stakeholders. This presentation will guide the
initiated with a Sprint planning meeting, where the inspection of developed functionalities and possible
Product Owner and Team get together to collaborate adjustments to the project.
about what will be done for the next Sprint. Selecting At the end of the Sprint, a Sprint review meeting is
from the highest priority Product Backlog, the Product held at which the Team presents what was developed
Owner tells the Team what is desired, and the Team during the Sprint to the Product Owner and any
tells the Product Owner how much of what is desired stakeholders who wish to attend. After the Sprint
can be turned into functionality over the next Sprint. In review and prior to the next Sprint planning meeting,
the first sprints, most of architecture and infra-structure the ScrumMaster also holds a Sprint retrospective
work are done, so less functionalities are released. meeting in order to encourage the Team to revise,
within the Scrum process framework, its development
Table 1. Scrum’s roles and responsibilities process to make it more effective and enjoyable for the
Role Responsibilities next Sprint.
Product Represents the interests of everyone
Owner with a stake in the project and its
resulting system. Maintains the
Product Backlog, i.e., a prioritized list
of project requirements with
estimated times to turn them into
completed product functionality.
Team Responsible for developing
functionality. Teams are self-
managing, self-organizing, and
cross-functional, and they are
responsible for figuring out how to
turn Product Backlog into an
increment of functionality within an
iteration and managing their own
work to do so. Team members are Figure 1. Scrum process overview, from Agile
collectively responsible for the Project Management with Scrum [17].
success of each iteration and of the
project as a whole. Schwaber [17] concludes saying that together, the
ScrumMaster Responsible for managing the Scrum Sprint planning meeting, the Daily Scrum, the Sprint
process, i.e., for teaching Scrum to review, and the Sprint retrospective constitute the
everyone involved in the project, for empirical inspection and adaptation practices of
implementing Scrum so that it fits Scrum.4. Author name(s) and affiliation(s)
within an organization's culture and
still delivers the expected benefits,
and for ensuring that everyone 3. Mapping CMMI Project Management
follows Scrum rules and practices. Proscess Areas to Scrum Practices

After deciding what has to be done in the next The mapping between CMMI process areas and
Sprint, the Team develops the Sprint Backlog, i.e., a Scrum practices considers the staged representation of
list of tasks that must be performed to deliver a CMMI-DEV[5] model, version 1.2, released in August,
completed increment of potentially shippable product 2006. The assessment only considers the project
functionality by the end of the Sprint. The sub-tasks in management process areas (Table 2), as this was its
the list emerge as the Sprint evolves and should be focus.
divided so that each takes roughly 4 to 16 hours to For each process area, a mapping between its
finish. specific practices and the SCRUM practices was
During the execution of each sprint, the team meets carried out. Several considerations were identified in
daily in 15-minute meetings to track work progress and order to establish this mapping, identifying gaps and
schedule other meetings, if necessary. At the Daily strengths. After that, a coverage rating for each
Scrum, each Team member answers three questions:
practice was established considering the following
criteria in Table 3. SP 1.2 Establish Estimates of Work Product and
Task Attributes. Its purpose is to define what is
Table 2. CMMI Project Management Process necessary to establish and maintain estimates of the
Areas attributes of the work products and tasks. There are no
Level Process Area explicit orientations in SCRUM to establish, for
Level 2 Project Planning instance, size and/or complexity of items of Product
Project Monitoring and Control Backlog and Sprint Backlog. Beyond that, no method
Supplier Agreement Management is explicitly mentioned to guide the estimates, such as
Level 3 Integrated Project Management +IPPD WideBand Delphi, Function Point Analysis, Use Case
Risk Management
Points or Story Points. In this way, this practice is
Level 4 Quantitative Project Management
Unsatisfied.
After the rating phase, a coverage percentage for
SP 1.3 Define Project Lifecycle. Its purpose is to
each process area was calculated based on the total
define a project lifecycle on which to scope the
quantity of specific practices. Afterwards, the results
planning effort. This practice is fully addressed by
were grouped and a complete view of the CMMI
SCRUM because it defines a lifecycle as showed by
project management process areas coverage by
Larman [12], composed of 4 phases:
SCRUM practices was generated. Each mapping and
• Planning: establishes a project vision and the
the general results are described in next sub-sections.
stakeholders expectations, beyond assuring
funding/budgeting for project execution.
Table 3. Criteria for practices rating • Staging: identifies and prioritizes the requirements
Rating Criteria
(at least, for the next sprint). Break the Product
U Unsatisfied The practice is not addressed by
Scrum Backlog in Sprints, according to previous priorization,
PS Partially There is some evidence of the considering the team productivity.
Satisfied practice being addressed by Scrum, • Development: implements the system in a set of
however the practice is not fully 30-day iterations (sprints), when, at the end of each
addressed. sprint, a product increment is presented to the
S Satisfied The practice is fully addressed. stakeholders.
• Release: System deployment.
3.1. Mapping the Process Area Project So, this practice is Satisfied.
Planning
SP 1.4 Determine Estimates of Effort and Cost. Its
According to CMMI-DEV[[5]], the purpose of purpose is to estimate the project effort and cost for the
Project Planning (PP) is to establish and maintain plans work products and tasks based on estimation rationale.
that define project activities. PP has 3 specific goals In SCRUM, estimates are carried out on 2 levels:
(SG 1 Establish Estimates, SG 2 Develop a Project Product backlog and Sprint Backlog. Product Backlog
Plan, SG 3 Obtain Commitment to the Plan) enclosing estimates are high level estimates, so less accurate,
14 specific practices. The mapping of all specific providing a visibility of each requirement size (effort).
practices related to this process area is presented Sprint Backlog estimates are more accurate than the
below. first ones. Team estimation is calculated by
performance on previous sprints, capacity for the
SP 1.1 Estimate the Scope of the Project. Its purpose forthcoming sprint and the relative complexity of the
is to establish a top-level work breakdown structure tasks required to deliver the Sprint Goal [6]. However,
(WBS) to estimate the scope of the project. In these effort estimates don’t follow a formal method nor
SCRUM, the initial definition of the project’s scope are they derived from size or complexity as required by
occurs during the Pre-Game Planing phase, when the the CMMI model. SCRUM doesn’t mention the
stakeholders can contribute to Product Backlog importance of using a historical base. Cost is not
creation. In this case, the WBS is composed of the explicitly mentioned in SCRUM, just effort, but it is
Product Backlog and the set of all pre-defined sprints, necessary for the Product Owner to calculate the
providing the necessary resources to estimate the project’s budget and funding. In this way, this practice
project’s scope. Detailed estimates are carried out at is classified Partially Satisfied.
the beginning of each sprint, in the second part of the
Sprint Planning meeting. So, this practice is Satisfied. SP 2.1 Establish the Budget and Schedule. Its
purpose is to establish and maintain the project’s
budget and schedule. In SCRUM, the project’s budget as: identifying what knowledge and skills are needed,
and schedule are obtained from Product Backlog and analyzing the knowledge and skills of the available
directly derived from the estimated effort. Product resources and selecting the mechanisms to provide
Backlog is prioritized and subdivided in Sprints, knowledge and skills not found in the organization. In
considering team allocation and its workload. The this way, this practice is considered Unsatisfied.
schedule is composed of a set of 30-day sprints. On the
other hand, SCRUM doesn’t provide orientations about SP 2.6 Plan Stakeholder Involvement. Its purpose is
establishing budget. Considering this gap, this practice to involve identified stakeholders. SCRUM defines
was rated Partially Satisfied. how stakeholders will be involved during the project’s
execution. This involvement is monitored by the
SP 2.2 Identify Project Risks. Its purpose is to Scrum Master and registered in a communication plan.
identify and analyze project risks. SCRUM considers a In this way, this practice is considered Satisfied.
risk as a possible impediment for the project. The risks
identification occurs in an iterative way, during daily SP 2.7 Establish the Project Plan. Its purpose is to
meetings and registered on white-boards, flipcharts or establish and maintain the overall project plan content.
impediments list. But, this risk identification doesn’t According to Schwaber [17], the minimum plan
occur in a systematic and parametrized manner, using, necessary to start a Scrum project consists of a vision
for instance, risk categories and sources. So, this and a Product Backlog. The vision describes why the
practice is Partially Satisfied. project is being undertaken and what the desired end
state is. The Product Backlog defines the functional
SP 2.3 Plan for Data Management. Its purpose is to and non functional requirements that the system should
plan for the management of project data. The practices meet to deliver the vision, prioritized and estimated.
and rules defined in SCRUM contribute for good Vision document and product backlog create a base for
communication and promote collaboration between elaborating a high-level project plan. So, this practice
team and stakeholders, beyond providing visibility of is rated Satisfied.
project progress. According to Schwaber [17], any data
generated by the project must be stored in a public SP 3.1 Review Plans That Affect the Project. Its
folder, available to everyone. Much project purpose is to review all plans that affect the project to
information is communicated through meetings or understand project commitments. In SCRUM, plans
documents. However, there is no formal procedure to are revised at the beginning of each sprint and possible
collect, consolidate and publish this information and adaptations are carried out in accordance with change
data. Data privacy is another weakness, so this practice requirements and technologies. The CMMI model
is Unsatisfied. doesn’t explicit which plans need to be revised, such as
the QA plan, the CM plan nor the Test plan amongst
SP 2.4 Plan for Project Resources. This practice others. Therefore, this practice is considered Satisfied.
plans the necessary resources for the project to run. In
SCRUM, team allocation and infra-structure SP 3.2 Reconcile Work and Resource Levels. Its
availability are carried out at the beginning of the purpose is to reconcile the project plan to reflect
project. During its execution, the Scrum Master is available and estimated resources. This practice is
responsible for providing new resources when the Satisfied, because this work reconciliation occurs
actual resources aren’t enough or new impediments during the Sprint Planning meeting. The team, Product
related to insufficient resources are reported in the Owner and Scrum Master define the functionalities to
daily meetings. This practice is Satisfied. be developed in the sprint.

SP 2.5 Plan for Needed Knowledge and Skills. This SP 3.3 Obtain Plan Commitment. This practice
practice focuses on the planning for knowledge and addresses the commitment from relevant stakeholders
skills needed to perform the project. In SCRUM, teams responsible for performing and supporting plan
are multi-functional groups, self-managed, made up of execution. The plan commitment occurs continuously
7 skilled people implementing the Sprint Backlog at the beginning of each sprint, during the Sprint
items. The team is composed of analysts, designers, Planning Meeting. The Product Owner, the Scrum
QA, developers, data administrators, and architects Master and the team define the priorities of Product
amongst others. Senior members must mentor, monitor Backlog for each sprint and which items are to be
and guide other members. However, SCRUM doesn’t developed in the next sprint. During the Sprint
mention the necessity of planning the knowledge and execution, if the team workload is not enough to
skills needed to perform the project’s activities, such develop all the agreed items, the Product Owner can
decide which sprint backlog item could be removed. model. So, trainings tracking is also informal, due to
On the other hand, if the team workload is greater than the fact that there is no formal planning. In this way,
the effort necessary to implement the Sprint Backlog this practice is rated Partially Satisfied.
items, Product Owner can allocate other items from
Product Backlog. Therefore, this practice is Satisfied. SP 1.2 Monitor Commitments. Its purpose is to
The general rating for this process area is shown in monitor commitments against those identified in the
Figure 2. project plan. In SCRUM, commitments of each sprint
are established during the Sprint Planning Meeting and
monitored through Sprint Burndown and daily
meetings and, finally, reviewed in the Sprint
Retrospective Meeting. During a sprint, the team
cannot receive any additional work from stakeholders
or Product Owner. Just the team itself can update
Sprint Backlog in order to maintain uninterrupted
Figure 2. General coverage for Project Planning focus on Sprint activities. So, this practice is rated
process area Satisfied.

3.2. Mapping the Process Area Project SP 1.3 Monitor Project Risks. Its purpose is to
Monitoring and Control monitor risks against those identified in the project
plan. In SCRUM, the daily meeting can help to
The purpose of Project Monitoring and Control identify impediments (issues, dependencies, risks etc),
(PMC) is to provide an understanding of the project’s so risks are identified but they are not analyzed
progress so that appropriate corrective action is taken properly. Risks are registered on whiteboards,
when the project’s performance deviates significantly flipcharts or impediment lists and monitored by the
from the plan [5]. PMC encloses 10 specific practices Scrum Master, so they are tracked in a informal way.
grouped in 2 specific goals (SG 1 Monitor Project In other words, this practice is considered Partially
Against Plans and SG 2 Manage Corrective Action to Satisfied.
Closure). The mapping of all specific practices related
to this process area is presented below. SP 1.4 Monitor Data Management. Its purpose is to
monitor the management of project data against the
SP 1.1 Monitor Project Planning Parameters. Its project plan. This practice is Unsatisfied because
purpose is to monitor the actual values of the project SCRUM doesn’t adopt any procedure for planning and
planning parameters against the project plan. In tracking data management, as required by CMMI
SCRUM, project tracking occurs through Burndown model.
graphs and project meetings previously mentioned.
Product Burndown shows the speed of releasing SP 1.5 Monitor Stakeholder Involvement. Its
Product Backlog items by the team. It is analyzed at purpose is to monitor stakeholder involvement against
the end of each Sprint. It helps to monitor the planning the project plan. In SCRUM, stakeholders involvement
of functionalities releasing, providing visibility if the tracking is carried out during project meetings by the
sprint goal will be successfully achieved or if re- Scrum Master, who is responsible for assuring that all
planning the sprint’s scope is required to achieve the stakeholders understand and respect the rules and
planned date. Sprint Burndown daily shows the speed practices defined in SCRUM. In spite of there not
of the team and the progress of its activities in a Sprint. being any register of this monitoring, this practice is
Sprint Burndown provides a supporting tool for Satisfied because it is possible to find indirect evidence
planning necessary corrective actions. such as impediment list updated, Product Backlog and
Tracking meetings, mainly daily meetings, allows a Sprint Backlog updated amongst others.
day-by-day tracking of the team’s progress and
assesses the current difficulties of carrying out the SP 1.6 Conduct Progress Reviews. Its purpose is
planned activities. These difficulties must be quickly periodically reviewing the project's progress,
overcome by the Scrum Master so that the team performance, and issues. In SCRUM, project control is
doesn’t lose its focus or Sprint goal. carried out by frequent inspections and progress review
In spite of that, like cost, size and effort estimates meetings (the Daily Meeting and Sprint Review
are not carried out in a sistematic manner, there is not a Meeting). In this way, this practice is fully Satisfied.
formal tracking of them as required by the CMMI
SP 1.7 Conduct Milestone Reviews. Its purpose is to suppliers [5]. In SCRUM, there is not any practice
review the accomplishments and results of the project addressing the acquisition of products and product
at selected project milestones. As commented in SP components that are delivered to the project’s
1.6, milestone reviews occur at the end of each Sprint. customer. So, all of its specific practices are
In Sprint Review Meetings, the project progress is Unsatisfied.
inspected, providing visibility of the accomplishment
of commitments. Therefore, this practice is considered 3.4 Mapping the Process Area Integrated
Satisfied. Project Management + IPPD
SP 2.1 Analyze Issues. Its purpose is to collect and According to CMMI-DEV[5], the purpose of
analyze the issues and determine the corrective actions Integrated Project Management (IPM) is to establish
necessary to address the issues. During the Daily and manage the project and the involvement of the
Scrum Meetings, the team reports all impediments relevant stakeholders according to an integrated and
against expected quality or performance levels. defined process that is tailored from the organization’s
Impediments are registered on a whiteboard, flipchart set of standard processes. For Integrated Product and
or impediment list and they are erased when overcome. Process Development (IPPD), IPM + IPPD also covers
Beyond that, the Scrum Master is in charge of the establishment of a shared vision for the project and
resolving the impediments as soon as possible, taking the establishment of integrated teams that will carry
appropriate corrective actions. So, this practice is out objectives of the project.
Satisfied. IPM + IPPD is composed of 3 specific goals (SG 1
Use the Project’s Defined Process, SG 2 Coordinate
SP 2.2 Take Corrective Action. Its purpose is to take and Collaborate with Relevant Stakeholders and SG 3
corrective action on identified issues. As mentioned Apply IPPD Principles) enclosing 14 specific
before, corrective actions are taken for the practices.
impediments found. However, there is not any register In this process area, all of the 6 specific practices
of how these actions are planned and monitored. So, related to SG1 (“the project is conducted using a
this practice is Partially Satisfied. defined process that is tailored from the organization's
set of standard processes”) are assessed Unsatisfied.
SP 2.3 Manage Corrective Action. Its purpose is to Because SCRUM doesn’t define a set of organizational
manage corrective actions to closure. As mentioned standard processes, it just establishes a set of practices
before, impediments registered on the whiteboard, and rules defined for the project. In other words, the
flipchart or impediment list are erased when resolved. project’s defined process is not derived from a set of
So, all corrective actions are monitored to closure. organizational processes.
However, the results of these actions are not analyzed The mapping of other specific practices related to
to determine its effectiveness. Therefore, this practice this process area is presented below
is Partially Satisfied.
The general rating for this process area is shown in SP 2.1 Manage Stakeholder Involvement. Its
Figure 3. purpose is to manage the involvement of the relevant
stakeholders in the project. As commented before, in
PMC SP 1.5, SCRUM practices and rules implicitly
define how stakeholders will be involved in the project
tracking. This involvement is monitored by the Scrum
Master. So, in this way, this practice is Satisfied.

SP 2.2 Manage Dependencies. Its purpose is to

participate with relevant stakeholders to identify,
negotiate, and track critical dependencies. In SCRUM,
Figure 3. General coverage for Project
dependencies and risks can be managed as
Monitoring and Control process area
impediments, being identified through Scrum Daily
Meetings. The Scrum Master is in charge of resolving
3.3. Mapping the Process Area Supplier any identified problem as soon as possible, including
Agreement Management dependencies. However, there are no registers of
negotiation, meeting minutes or agreed dates to remove
The purpose of Supplier Agreement Management such dependencies. Beyond that, there is no planning
(SAM) is to manage the acquisition of products from
of tracking strategies or verification of the functionalities in the SCRUM staging phase,
dependencies. Therefore, this practice is Partially before the first sprint;
Satisfied. • Always release business value in the sprints
carried out for building the infra-structure;
SP 2.3 Resolve Coordination Issues. Its purpose is to • Optimize the initial team capabilities and prepare
resolve issues with relevant stakeholders. This practice additional teams. Additional teams must be
is Partially Satisfied, for the same reasons presented for composed of, at least, 1 member of the initial
SP 2.2. team, playing an infra-structure and architect
expert role.
SP 3.1 Establish the Project’s Shared Vision. Its All of these practices establish the necessary
purpose is to establish and maintain a shared vision for requirements of integrating teams. So, this practice is
the project. The Scrum planning process sets the Satisfied.
stakeholders' expectations. The plan is a way of
syncronizing stakeholders' expectations with the team's SP 3.4 Establish Integrated Teams. Its purpose is to
expectations [17]. It is also important that the whole establish and maintain integrated teams in the
team understands the essence of what the project or structure. This practice is Satisfied, for the same
product is trying to achieve. This is where the Project reasons presented for SP 3.2 e SP3.3.
Vision comes in. It should be as short and as accessible
as possible but communicates the substance and SP 3.5 Ensure Collaboration among Interfacing
character of the undertaking [6]. Therefore, this Teams. This practice ensures collaboration among
practice is Satisfied. interfacing teams. This practice is Satisfied, due to the
same reasons presented for SP 3.2 e SP3.3.
SP 3.2 Establish the Integrated Team Structure. Its The general rating for this process area is shown in
purpose is to establish and maintain the integrated team Figure 4.
structure for the project. In SCRUM, when several
teams work in a collaborative environment, this project
is called scaled project and the mechanisms used to
coordinate their activities are called scaling
mechanisms [17]. When scaling Scrum to larger
projects some guidelines must be followed:
• Attempt to keep the team size to eight.
• Do not engage all the teams until the infrastructure
is built. This may require the first few sprints Figure 4. General coverage for IPM+IPPD
being done by only a single team and primarily process area
non-functional requirements being built.
• Divide the work into teams that logically represent
the work and minimize the need for multiple 3.5 Mapping the Process Area Risk
assignments of people. Management
• Create a daily scrum meeting of representatives
from each scrum, held after the daily scrum. The purpose of Risk Management (RSKM) is to
So, these guides help to establish an integrated team identify potential problems before they occur so that
structure and this practice is Satisfied. risk-handling activities can be planned and invoked as
needed across the life of the product or project to
SP 3.3 Allocate Requirements to Integrated Teams. mitigate adverse impacts on achieving objectives [5].
Its purpose is to allocate requirements, responsibilities, As previously mentioned, in SCRUM, risks are
tasks, and interfaces to teams in the integrated team identified, but it doesn’t mention practices to define
structure. In SCRUM, some practices are critical for sources, parameters or categories to analyze and
the scaled project success, such as [17]: control the risk management effort. In SCRUM, there
• Build a scalable infra-structure before scaling the are no strategies for risk response or a mitigation plan
project. This structure must support just one team for the critical risks based on historical bases or
initially and grows during successive sprints. Non similar. In this way, the assessment, categorization and
functional requirements to build the scaling infra- priorization of these risks occur in an informal manner.
structure must to be added to the Product Backlog Therefore, all of the specific practices of RSKM are
and prioritized jointly with other business
Unsatisfied, except SP 2.1 Identify Risks, because it is
Partially Satisfied.
The general rating for this process area is shown in
Figure 5.

Figure 6. CMMI Project Management Process

Areas covered by Scrum

Considering each CMMI project management

process area according to its maturity level, another
analysis can be made as shown in Figure 7.
Figure 5. General coverage for Risk
Management process area

3.6 Mapping the Process Area Quantitative

Project Management

The purpose of Quantitative Project Management

(QPM) is to quantitatively manage the project’s
defined process to achieve the project’s established
quality and process-performance objectives [5].
According to CMMI-DEV, in this process area, the Figure 7. CMMI Project Management Process
quality and process-performance objectives, measures, Areas covered by Scrum. Rating grouped by
and baselines identified are developed as described in maturity level, considering only the project
the Organizational Process Performance process area. management process area category
Subsequently, the results of performing the processes
associated with the Quantitative Project Management In this way, process areas related to maturity level 2
process area (e.g., measurement definitions and (PP, PMC and SAM) have 40,6% of its specific
measurement data) become part of the organizational practices Satisfied by SCRUM, 21,9% are Partially
process assets referred to in the Organizational Process Satisfied and 37,5% are Unsatisfied. If SAM is not
Performance process area. In SCRUM, there is not any applicable to the organization context, SCRUM
practice addressing this process area. Therefore, all of becomes more attractive (54,2% Satisfied, 29,2%
its practices are Unsatisfied. Partially Satisfied and 16,7% Unsatisfied).
But things don’t sound so good when considering
3.7 Overall Results from the Mapping process areas related to maturity level 3 (IPM+IPPD
and RSKM). These process areas have 28,6% of its
General results of the mapping are shown in Figure specific practices Satisfied by SCRUM, 14,3% are
6, a consolidated view of the coverage of CMMI Partially Satisfied and 57,1% are Unsatisfied, due to a
project management process areas by SCRUM weak adherence of SCRUM to RSKM practices, lack
practices. of organizational process and systematic use of
This result shows that 31,1% of specific practices of historical bases, as required by IPM process area.
CMMI project management process areas are Satisfied, Finally, considering process areas related to maturity
16,4% are Partially Satisfied and 52,5% are level 4, these specific practices are 100% Unsatisfied
Unsatisfied. In other words, SCRUM is not fully by SCRUM.
complaint with CMMI project management process
areas, mainly related to SAM, RSKM and QPM 4. FINAL CONSIDERATIONS
process areas. If SAM and QPM are not considered,
42,2% of the specific practices of CMMI project The goal of this research was to compare the agile
management process areas are Satisfied, 22,2% are method Scrum to the Project Management process
Partially Satisfied and 35,6% are Unsatisfied. areas of the CMMI model, showing the gaps and the
strengths between them. From this mapping we
conclude that Scrum does not cover all the specific
practices of the project management process area, but it [7] Goldenson, D., and D. L. Gibson. “Demonstrating the
could be tailored to be more compliant with CMMI. Impact and Benefits of CMMI: An Update and Preliminary
On the other hand, we can conclude that a plan-driven Results”, CMU/SEI-2003-SR-009, Software Engineering
process based on CMMI model can be improved by Institute, 2003.
adding some Scrum agile practices to their activities.
[8] Herbsleb, J., A Carleton, J Rozum, J. Siegel, and D.
Therefore, SCRUM is a recommended starting Zubrow, “Benefits of CMM-Based Software Process
point for organizations with small teams and without Improvement: Initial Results”, CMU/SEI-94-TR-013,
defined processes, because most of the necessary Software Engineering Institute, 1994.
fundamentals for institutionalizing CMMI project
management process areas related to maturity level 2 [9] Highsmith, J., “Agile Project Management. Creating
are created without compromising the agility needed Innovative Products”, Addison-Wesley, 2004.
by these organizations. However, organizations
searching higher maturity levels are not fully met by [10] Highsmith, J., “Agile Software Development
Ecosystems”, Addison–Wesley, Boston, MA, 2002.
SCRUM practices. Other alternative practices are
necessary to complement SCRUM and address CMMI [11] Kähkönen, T., and P. Abrahamsson, "Achieving CMMI
requirements. The great challenge is identifying how Level 2 with Enhanced Extreme Programming Approach", In
alternative practices can complement SCRUM without proceedings of the 5th International Conference on Product
losing agility. Focused Software Process Improvement, pp. 378-392, 2004.
In light of that, suggestions for future work could
be: extension of this mapping with CMMI generic [12] Larman, C., “Agile & Iterative Development. A
practices; inclusion of mapping with other agile Manager’s Guide”, Addison-Wesley, 2004.
methodologies in order to establish a complete view of
[13] Menezes, W., "To CMMI or Not to CMMI: Issues to
how other methodologies can address CMMI project Think About", Crosstalk, February 2002.
management practices; and the definition of a new
agile project management methodology considering the [14] Nawrocki, J., W. Bartosz, and A. Wojciechowski,
best practices found in the previous work mapping and "Toward Maturity Model for eXtreme Programming", In
some alternative practices of Agile Project proceedings of the 27th Euromicro Conference, pp. 233-239,
Management [9], if necessary. 2001.

[15] Paulk, M. C., "Extreme Programming from a CMM

10. References Perspective Software”, vol. 18, issue 6, pp. 1926, 2001.
[1] Alleman, G., “Blending Agile Development Methods
[16] Pikkarainen, M., and A. Mäntyniemi, “An Approach for
with CMMI”, Cutter IT Journal, Vol. 17, No. 6, June 2004.
Using CMMI in Agile Software Development Assessments:
Experiences from Three Case Studies”, SPICE 2006
[2] Anderson, D. J., "Stretching Agile to fit CMMI Level 3",
Conference, Luxemburg, May 2006.
presented at Agile 2005 Conference, Dever,
http://www.agilemanagement.net/Articles/Papers/Agile_2005
[17] Schwaber, K., “Agile Project Management With
_Paper_DJA_v1_5.pdf , 2005.
Scrum”, Microsoft, 2004.
[3] Beck, K., et al., “Manifesto for Agile Software
[18] Schwaber, K., “Controlled chaos: living on the edge”,
Development, http://www. agilemanifesto.org/, (December
http://www.controlchaos.com/old-site/ap.htm, (December
2006).
2006).
[4] Boehm, B., “A View of 20th and 21st Century Software
[19] Turner, R., and A. Jain, "Agile Meets CMMI: Culture
Engineering”, ICSE 2006, May 2006.
Clash or Common Cause", In proceedings of the Second XP
Universe and First Agile Universe Conference on Extreme
[5] CMMI-DEV, “CMMI for Development”, V1.2 model,
Programming and Agile Methods XP/Agile Universe, pp.
CMU/SEI-2006-TR-008, Software Engineering Institute,
153-165, 2002.
2006.
[20] Zubrow, D., "Current Trends in the Adoption of the
[6] Cochango, “Scrum for team systems”,
CMMI Product Suite," In Proceedings of the 27th Annual
http://www.scrumforteamsystem.com, (December 2006).
International Computer Software and Applications
Conference, pp. 126-129, 2003.