Page 1
Excellence in Measurement Technology presents:
The EMT CMMI®/ISO 9001/Agile/SAFe® CrosswalkHow to use this crosswalk: This crosswalk spreadsheet organizes the information from CMMI®, ISO 9001, Agile, and SAFe® into a matrix that allows you to see how the practices from each methodology relate
to CMMI Specific Practices, and vice versa. The methodologies referenced are CMMI® for Development v1.3, ISO 9001:2015, Scrum and Kanban applications of Agile, and SAFe
4.0.
To use the CMMI®/ISO 9000/Agile/SAFe® Crosswalk, you will need a solid grasp on CMMI for Development® v1.3 and its practices.
We recommend that at a minimum, you have taken the CMMI Institute's couse "Intro to CMMI® for Development"
Understanding of the other methodologies in the crosswalk that you are interested in (ISO 9001, Agile, SAFe®) is also recommended.
This crosswalk is organized by CMMI Process Areas, and their Specific Goals and Specific Practices.
Each Specific Practice contains a list of the practices from each methodology that are related or relevant to the CMMI Specific Practice. Not all Specific Practices have a
corresponding example from each methodology (for example, the typical Scrum implementation of Agile does not address organizational-level management and work). See the
diagram below for more information on how the crosswalk works.
Things to be aware of
when using this crosswalk:
This crosswalk is intended for use to compare related practices between CMMI® and the other methodologies only. It is not intended for comparing ISO 9001 with Agile or ISO 9001
with SAFe®. This crosswalk does show which practices from Agile and SAFe® are related to each other (see diagram), however we urge caution for doing this as it is only intended to
compare other methodologies to CMMI®.
A copy of the ISO 9001:2015 publication is needed to use this crosswalk for ISO 9001:2015. The information for ISO 9001:2015 in the crosswalk does not include the full text from
the ISO 9001:2015 publication. The information in the "ISO 9001:2015 QMS Clauses" column contains only partial information for reference so that you can find and look up the
complete text of the clause in the official publication. Using this crosswalk to compare ISO 9001:2015 and CMMI® without using the ISO 9001:2015 for reference will result in a
misunderstanding of the ISO 9001:2015 information in the crosswalk.
This crosswalk is not Objective Evidence of Specfic Goal implementation for a CMMI Appraisal for an organization that practices ISO 9001:2015, Agile, or SAFe. This crosswalk is
intended as reference only. It can be used to determine what practices from other methodologies may fulfill a CMMI Specific Practice, but an organization's implementation of an ISO
9001:2015, Agile, or SAFe practice must still be evaluated by the Appraisal Team and Lead Appraiser of the CMMI Appraisal to determine whether it actually fulfills the CMMI
Specific Practice or not.
Diagram of the
crosswalk spreadsheet:
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Instructions, Page 1
Page 2
Legal stuff: Copyright Excellence in Measurement Technology, LLC, 2017. All rights reserved.
CMMI®, the CMMI® logo, Data Management Maturity (DMM), and SCAMPI are registered marks of CMMI Institute LLC.
CMMI® for Development v1.3 and CMMI® for Services v1.3 are copyright of Carnegie Mellon University, 2010.
ISO 9001:2015 is copyright of the International Organization for Standardization, 2015.
Scaled Agile Framework® and SAFe® are registered trademarks of Scaled Agile, Inc.
The Scaled Agile Framework® is copyright © 2010-2017 Scaled Agile, Inc.
This crosswalk is not endorsed, approved or certified by the CMMI Institute, The International Organization for Standardization or Scaled Agile, Inc.
No Warranty: This Excellence in Measurement Technology material is furnished on an "as-is" basis. Excellence in Measurement Technology makes no warranties of any kind, either
expressed or implied, as to any matter inclulding, but not limited to, warranty of fitness for purpose or merchantability, exclusivity, or results obtained from use of the material.
Excellence in Measurement Technology does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.
Use of any trademarks in this material is not intended in any way to infringe on the rights of the trademark holder.
Internal use: Permission to reproduce this document for internal use is granted, provided the copyright, the Excellence in Measurement Technology trademark and logo, and “No
Warranty” statements are included with all reproductions.
External use: External and/or commercial use including, but not limited to, reproduction, modification, and distribution is prohibited.
For more information: To learn how Excellence in Measurement Technology can help you implement CMMI®, ISO 9001:2015, Agile, SAFe®, or implement more than one of these methodologies together,
visit our website at http://excellenceinmeasurement.com/.
To learn more about CMMI® and to download a free copy of the CMMI® for Development and CMMI® for Services models, visit the CMMI Institute's website at
http://cmmiinstitute.com/.
To learn more about the ISO 9001:2015 standard and to purchase a publication, visit the International Organization for Standardization's website at https://www.iso.org/.
To learn more about the Scaled Agile Framework, visit the Scaled Agile Framework website at http://www.scaledagileframework.com/.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Instructions, Page 2
Page 3
Causal Analysis and Resolution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Root causes of selected outcomes are systematically
determined.
SP1.1 Select outcomes for analysis.
7.2: Awareness: d) the implications of not
conforming with the quality management system
requirements.
The number of defects found in the product,
whether build defects found in testing, defects
found by the Product Owner in User Acceptance
Testing, or defects found after product release,
can be used to track the quality of the product.
The number of defects found in the product,
whether build defects found in testing, defects
found by the Product Owner in User Acceptance
Testing, or defects found after product release,
can be used to track the quality of the product.
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 2) deal with the consequences; b)
evaluate the need for action to eliminate the
cause(s) of the nonconformity, in order that it
does not recur or occur elsewhere, by: 1)
reviewing and analysing the nonconformity; 2)
determining the causes of the nonconformity;
During the Retrospective and Problem-Solving
Workshop, the teams select and agree on the
problem to solve. This can be done by
collaborating to create a problem statement.
SP1.2Perform causal analysis of selected outcomes and propose actions
to address them.
7.2: Awareness: d) the implications of not
conforming with the quality management system
requirements.
The Sprint Retrospective may discuss the
number of defects found and how to address
defect prevention.
The Iteration Retrospective may discuss the
number of defects found and how to address
defect prevention.
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 2) deal with the consequences; b)
evaluate the need for action to eliminate the
cause(s) of the nonconformity, in order that it
does not recur or occur elsewhere, by: 1)
reviewing and analysing the nonconformity; 2)
determining the causes of the nonconformity;
During the Retrospective and Problem-Solving
Workshop, root cause analysis is performed
using problem-solving tools such as Fishbone
Diagrams and the Five Whys. Pareto analysis is
then performed to determine the biggest factors
causing the problem. The biggest cause is
restated as a problem, and a brainstorming
session takes place to generate solutions. The
three most likely solutions are fed into the
backlog as Improvement Stories and Features.
SG2Root causes of selected outcomes are systematically
addressed.
SP2.1 Implement selected action proposals developed in causal analysis.
Appraisal Considerations:
- The scope of causal analysis in terms of the defects to be analyzed is identified.
The organization may choose to analyze all defects or a subset of total defects
detected. It is recommended that a causal analysis be done for a subset of defects
that offer maximum benefits.
The most important criteria to apply for selection of defects is that it should provide
the maximum benefit to the project
Some of the criteria are
- Defects attributed to most prevalent defect type
- All customer reported defects
- All high and medium severity defects
- Defects which require maximum rework
Artifact Example:
- Defect and/or problem data selected for further analysis (using, e.g., Histograms
or Pareto charts )
o - Metrics analysis meeting minutes showing discussion of the defect containment
metric issues
- Metrics Analysis meeting minutes showing example of selecting process
improvement metric for analysis
- Defect Management and Prevention Procedure
- Select Defect Data for Causal Analysis
- Guidelines for Defect Prevention
- Defect Prevention Action Planning Form
- Metrics Analysis Report
- Customer complaints
- Defect Tracking Form- Defect and/or problem list gathered from work product
reviews, testing, and process capability analysis
- Progress metrics show data related to plan and actuals that initiated process
improvement analysis effort
- QPM plan
Appraisal Considerations:
- Causal Analysis on the identified defects is performed by a causal analysis team.
The causal analysis is done formally using the Cause & Effect diagram (e.g.
Fishbone diagram) using a technique such as brainstorming.
Artifact Example:
- Action proposal
- Root causes determined ( using, e.g., Cause-and-effect diagram and/or Check
sheets)
- Action proposals corresponding to each of the defect or problem data
- Minutes from QPM metrics analysis meeting showing root cause and multiple
recommend actions (common cause)
- Defect Management and Prevention Procedure
- Guidelines for Defect Prevention
- Metrics Analysis Report
- Cause & Effect Diagrams
- Meeting minutes of Defect Prevention Meeting
- Meeting minutes from Causal Analysis session
- Defect Prevention Action Planning Form
- Defect Analysis Form
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CAR, Page 1
Page 4
Causal Analysis and Resolution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
9.2: Internal Audit: 9.2.2: e) take appropriate
correction and corrective actions without undue
delay;
The Sprint Retrospective meeting may generate
action items to improve for the next sprint.
The Iteration Retrospective meeting may
generate action items to improve for the next
sprint.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
SP2.2Evaluate the effect of implemented actions on process
performance.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: b) identified in order to determine
their status;
The Agile approach of inspecting and adapting
processes means that action items implemented
from the Sprint Retrospective meeting should be
evaluated for their effect on process
performance.
10.2: Nonconformity and corrective action:
10.2.1: d) review the effectiveness of any
corrective action taken;
The organization must determine and agree
upon which Metrics to use to measure their
quality and process performance, such as
program velocity, number of stories planned and
number of stories accepted, the number of
defects, and the unit test coverage percentage.
10.2: Nonconformity and corrective action:
10.2.2: b) the results of any corrective action.
SP2.3Record causal analysis and resolution data for use across work
groups and the organization.Appraisal Considerations:
- On a regular basis, the Organizational Process Group should be gathering
Defect Prevention data based upon their DP action plan from projects. This data,
gathered from across the organization, should be analyzed to identify the common
causes of defects across organization and take appropriate process improvement
actions.
Artifact Example:
- Causal analysis and resolution records
- CAR data recorded on organization’s measurement repository or process asset
library
- Defect Management and Prevention Procedure
- Guidelines for Defect Prevention
- Experience report of using CAR data
- Defect Prevention Action Planning Form
- Organization knowledge repository
10.2: Nonconformity and corrective action:
10.2.1: b) evaluate the need for action to
eliminate the cause(s) of the nonconformity, in
order that it does not recur or occur elsewhere,
by: 3) determining if similar nonconformities
exist, or could potentially occur;
The organization and scrum team must
determine how to capture and store causal
analysis and resolution records and how to use
them across scrum teams and the organization.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
Appraisal Considerations:
- From the preventive actions suggested during causal analysis meeting, actions
should be identified that can be implemented in the project immediately.
Responsibility should be assigned to complete those actions along with expected
completion dates and the expected results/benefits from those actions.
Artifact Example:
- Action plans for implementing selected proposals
- Improvement proposals
- Action proposals selected for implementation and corresponding action items
- Defect Management and Prevention Procedure
- Implemented Defect Prevention action plan
- Guidelines for Defect Prevention
- CAR process status sheet
Appraisal Considerations:
- Based on the defect data obtained subsequent to the defect prevention action
plan implementation, the defect prevention action effectiveness should be
evaluated and updated in a defect prevention planning document/form.
Artifact Example:
- Measures of performance and performance change.
- Documented measurement data of performance and performance change ( e.g.,
XmR charts of capable processes )
- Defect Management and Prevention Procedure
- Closure of Defect Prevention Action(s)
- Guidelines for Defect Prevention
- CAR process status sheet including improved common causes of process
variation that meet organization’s quality and process performance objectives
- Defect Prevention Action Planning Form - Expected Result - Actual Goal details
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CAR, Page 2
Page 5
Configuration Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1 Baselines of identified work products are established.
SP1.1Identify configuration items, components, and related work
products to be placed under configuration management.
4.3: Determining the scope of the quality
management system
The organization and scrum team must
determine their configuration management
needs and objectives and implement a process
for configuration management based on Agile
practices.
The organization must determine their
configuration management needs and
objectives and implement a process for
configuration management based on SAFe®
practices.
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
Putting everything under version control is one
of the six SAFe®-recommended practices for
establishing a deployment pipeline. This
includes all deployable artifacts, metadata, and
other supporting configuration items.
5.2: Policy: 5.2.2: Communicating the quality
policy: a) be available and be maintained as
documented information;
5.3: Organization roles, responsibilities and
authorities: e) ensuring that the integrity of the
quality management system is maintained when
changes to the quality management system are
planned and implemented.
6.2: Quality objectives and planning to achieve
them: 6.2.1: The organization shall maintain
documented information on the quality
objectives.
7.5: Documented information: 7.5.1: General
7.5: Documented information: 7.5.3: Control of
documented information
8.2: Requirements for products and services:
8.2.1: Customer communication: d) handling or
controlling customer property;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:The customer's
requirements shall be confirmed by the
organization before acceptance, when the
customer does not provide a documented
statement of their requirements.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: i) the level of control expected for the
design and development process by customers
and other relevant interest parties;
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: f) documented information of these
activities is retained.
Appraisal Considerations:
- Be sure to consider configuration items representative of all disciplines and
processes within the assessment scope and context. In a sense, this SP specifies
the constraints under which the remaining SPs should be considered and
assessed
- See model for definition and description of configuration item and its work
product components
- See model for typical examples of work products that may be part of a
configuration item (e.g. process descriptions, requirements, design, tools)
- See model overview material for GP2.6 for a description of the various levels of
control that might be provided across the lifecycle, e.g. version control vs. formal
configuration management
- “This process area applies not only to configuration management on projects, but
also configuration management on organization work products such as standards,
procedures, and reuse libraries.”
- Recall that this PA supports configuration management needs of all other
process areas, as invoked by GP2.6
Artifact Examples:
- Identified configuration items
- Configuration management lifecycle for controlled items (e.g., owner, point at
which placed under control, degree of control, change approval.)
- Configuration management plan
- Configuration item identifiers, attributes and characteristics
- Documented criteria for selecting configuration items
- Documented relationships among configuration items
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CM, Page 1
Page 6
Configuration Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.5: Production and service provision: 8.5.3:
Property belonging to customers or external
providers
SP1.2Establish and maintain a configuration management and change
management system for controlling work products.
4.3: Determining the scope of the quality
management system
The ScrumXP practice of Continuous
Integration/Continuous Build imply the use of a
code repository for configuration management.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build imply
the use of a code repository for configuration
management.
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
SAFe® Solution Intent practices for
documenting requirements, design, and
architecture include documenting items in only
one place.
7.5: Documented information: 7.5.3: Control of
documented information
Putting everything under version control is one
of the six SAFe®-recommended practices for
establishing a deployment pipeline. This
includes all deployable artifacts, metadata, and
other supporting configuration items.
SP1.3Create or release baselines for internal use and for delivery to the
customer.
4.3: Determining the scope of the quality
management system
User Stories establish requirement baselines
and are used to track requirements until
completion.
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
The Sprint Backlog shows all of the user stories
in a sprint and related tasks.
7.5: Documented information: 7.5.3: Control of
documented information
The Sprint Burndown Chart shows the status of
the work that the development team has
completed.
The Task Board shows which user stories and
tasks are ready to do, are in progress, are ready
to be accepted, and are done.
SAFe® Solution Intent practices for
documenting requirements, design, and
architecture include documenting items in only
one place.
Using the SAFe® practice of Model-Based
Systems Engineering (MBSE), documents
should be generated from information in system
models. Document templates should be defined
early as they will influence many of the model
Appraisal Considerations:
- “A configuration management system includes the storage media, the
procedures, and the tools for accessing the configuration system.”
- Look for evidence of consistent use of the CM system and change management
system for various types of work products (e.g. documentation, design, code, test)
across the development lifecycle
- Consider potential differences in CM processes and tools across the life cycle
(developmental CM, baseline control and management, archives, etc.)
- Demos of the CM tool and change management tool capabilities, with inspection
of random items, can serve as effective (affirmation) evidence of implementation of
this practice.
Artifact Examples:
- Configuration management system with controlled work products
- Configuration management system access control procedures
- Change request database
- Configuration management and change management procedures
- Configuration management system access control procedures
- CM library records and reports (e.g. baseline contents, level of controlled items,
audit reports)
- Change management database reports
- CM plan, describing tools and mechanisms for storage, retrieval, multiple levels
of control
- Records of the revision of the configuration management structure, as necessary
- CM backup and archive media
Appraisal Considerations:
- See model for definition of baseline (SP1.3 introductory text, and CMMI
glossary). Examples may include functional, allocated, and product baselines,
releases to a customer, or internal builds
- Consider different types of baselines that may be established for representative
work products throughout the project or product lifecycle and across the
disciplines being assessed.
Artifact Examples:
- Baselines
- Descriptions of baselines
- Baseline identifiers with defined and controlled contents (configuration items)
- Configuration management records and reports
- CCB meeting minutes
- Change documentation and version control associated with a baseline
- Baseline generation / release procedures, scripts, transmittal documents
- CM tool or repository demo (e.g., baselines, items, nodes, branches)
Appraisal Considerations:
- Be sure to consider configuration items representative of all disciplines and
processes within the assessment scope and context. In a sense, this SP specifies
the constraints under which the remaining SPs should be considered and
assessed
- See model for definition and description of configuration item and its work
product components
- See model for typical examples of work products that may be part of a
configuration item (e.g. process descriptions, requirements, design, tools)
- See model overview material for GP2.6 for a description of the various levels of
control that might be provided across the lifecycle, e.g. version control vs. formal
configuration management
- “This process area applies not only to configuration management on projects, but
also configuration management on organization work products such as standards,
procedures, and reuse libraries.”
- Recall that this PA supports configuration management needs of all other
process areas, as invoked by GP2.6
Artifact Examples:
- Identified configuration items
- Configuration management lifecycle for controlled items (e.g., owner, point at
which placed under control, degree of control, change approval.)
- Configuration management plan
- Configuration item identifiers, attributes and characteristics
- Documented criteria for selecting configuration items
- Documented relationships among configuration items
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CM, Page 2
Page 7
Configuration Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG2Changes to the work products under configuration
management are tracked and controlled.SP2.1 Track change requests for configuration items.
4.3: Determining the scope of the quality
management system
The Product Owner is responsible for creating
and maintaining the Product Backlog by adding
and prioritizing User Stories.
The Product Owner is responsible for creating
and maintaining the Team Backlog by adding
and prioritizing Stories.
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
The Sprint Review meeting may generate new
User Stories based on input from stakeholders,
which are added to the Product Backlog.
The Team Demo meeting may generate new
Stories based on input from stakeholders, which
are added to the Team Backlog.
7.5: Documented information: 7.5.2: Creating
and updating: c) review and approval for
suitability and adequacy.
A scaled Definition of Done may require Team
Increment assets to be under version control.
8.5: Production and service provision: 8.5.6:
Control of changes
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: c) the authorization of the changes;
SP2.2 Control changes to configuration items.
4.3: Determining the scope of the quality
management system
The ScrumXP practice of Continuous
Integration/Continuous Build imply the use of a
code repository for configuration management.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build imply
the use of a code repository for configuration
management.
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
The Product Owner is responsible for creating
and maintaining the Product Backlog by adding
and prioritizing User Stories.
The Product Owner is responsible for creating
and maintaining the Team Backlog by adding
and prioritizing Stories.
5.3: Organization roles, responsibilities and
authorities: e) ensuring that the integrity of the
quality management system is maintained when
changes to the quality management system are
planned and implemented.
A scaled Definition of Done may require Team
Increment assets to be under version control.
6.3: Planning of changes: b) the integrity of the
quality management system;
7.5: Documented information: 7.5.2: Creating
and updating
7.5: Documented information: 7.5.3: Control of
documented information
8.5: Production and service provision: 8.5.6:
Control of changes
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: c) the authorization of the changes;
SG3 Integrity of baselines is established and maintained
Appraisal Considerations:
- Typical change request contents include entries such as item identifier,
description of change, proposed change, rationale, impact analysis, review /
authorization, etc.
Artifact Examples:
- Change requests
- Change request tracking products (e.g., reports, logs, closure status, metrics)
- Recorded evaluation and disposition of change requests (e.g., review,
authorization, approval of changes)
- Change request impact analyses
- Change request lifecycle or workflow descriptions
- CCB / stakeholder review records (e.g., logs, meeting minutes)
- Configuration item revision history
Appraisal Considerations:
- Configuration items identified in SP 1.1 should be controlled at the appropriate
level
- Archives should be maintained for review / retrieval of superseded versions of
baselines and configuration items (e.g., to support rollback to prior versions)
- Typical change request contents include entries such as item identifier,
description of change, proposed change, rationale, impact analysis, review /
authorization, etc.
Artifact Examples:
- Revision history of configuration items
- Archives of the baselines
- Revised configuration items and baselines incorporating approved changes (e.g.,
CCB approval)
- Archives baseline
- Configuration management records and reports describing the revision status of
baselines and configuration items
- Impact analyses, reviews, or regression tests to ensure the integrity of baseline
revisions
- Change request review and tracking products (e.g., checklists, evaluation
criteria, reports, logs, closure status, metrics)
- Recorded evaluation and disposition of change requests (e.g., review,
authorization, approval of changes)
- Check-in/check-out procedures from the configuration management system.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CM, Page 3
Page 8
Configuration Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SP3.1 Establish and maintain records describing configuration items.
4.3: Determining the scope of the quality
management system
A card-based User Story system typically has
the requirements on the front side of the card,
and the verification steps to confirm the work
product meets the requirement on the back side
of the card.
The SAFe® requirements model requires
success criteria and/or acceptance criteria for
the resulting work products of Epics,
Capabilities, Features, Stories, and
Nonfunctional Requirements (NFRs).
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
Using the SAFe® practice of Model-Based
Systems Engineering (MBSE), documents
should be generated from information in system
models. Document templates should be defined
early as they will influence many of the model
standards.
7.5: Documented information: 7.5.2: Creating
and updating: a) identification and description;
8.5: Production and service provision: 8.5.6:
Control of changes
SP3.2Perform configuration audits to maintain the integrity of
configuration baselines.
4.3: Determining the scope of the quality
management system
The ScrumXP practice of Continuous
Integration/Continuous Build imply the use of a
code repository for configuration management.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build imply
the use of a code repository for configuration
management.
4.4: Quality management system and its
processes: 4.4.2: Quality management system
and its processes: a) maintain documented
information to support the operation of its
processes; b) retain documented information to
have confidence that the processes are being
carried out as planned.
The Product Owner is responsible for creating
and maintaining the Product Backlog by adding
and prioritizing User Stories.
The Product Owner is responsible for creating
and maintaining the Team Backlog by adding
and prioritizing Stories.
5.3: Organization roles, responsibilities and
authorities: e) ensuring that the integrity of the
quality management system is maintained when
changes to the quality management system are
planned and implemented.
6.3: Planning of changes: b) the integrity of the
quality management system;
8.5: Production and service provision: 8.5.6:
Control of changes
Appraisal Considerations:
- Configuration audits may take several forms (functional, physical, logical, etc.),
particularly when considering outside the software discipline
- The frequency and conduct of configuration audits are typically described in the
configuration management plan
- Configuration audits often include verifying activities described in other CM SPs,
such as CM system (SP1.2), baselines (SP1.3), change request tracking (SP2.1,
SP2.2), CM records (SP3.1)
- Consider horizontal audits (e.g. consistency of products across the baseline),
and vertical audits (e.g. authorization and incorporation of changes)
Artifact Examples:
- Configuration audit results
- Action items
- Action items for discrepancies determined as a result of configuration audits
- Criteria and checklists used to conduct configuration audits
- Configuration management system or libraries
- Change request logs or database
- Records describing content, status, and version of configuration items and
baselines
- Reports describing status of configuration items
- Quality inspection records
Appraisal Considerations:
- Ensure stakeholder access to configuration management records, baselines, and
configuration items, as appropriate
- How should the usage component (i.e., “establish and maintain”) be assessed
here?
Artifact Examples:
- Records describing content, status, and version of configuration items and
baselines
- Reports describing configuration item status, available to affected individuals and
groups (e.g., CM library reports, baseline access.)
- Revision history of configuration items
- Change log
- Copy of the change requests
- Change request logs or database
- Status of configuration items
- Differences between baselines
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CM, Page 4
Page 9
Decision Analysis and Resolution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Decisions are based on an evaluation of alternatives
using established criteria.
SP1.1Establish and maintain guidelines to determine which issues are
subject to a formal evaluation process.
4.3: Determining the scope of the quality
management system
The organization and scrum team must
determine which issues should be subject to a
formal evaluation and create and maintain
guidelines for entry criteria for formal evaluation
based on Agile practices.
SAFe® Principle #9 “Decentralize decision-
making” provides guidelines for which decisions
to centralize (those that are infrequent, long-
lasting, and have significant economies of
scale), and which decisions to decentralize
(those that are frequent, time-critical, and
require local information).
SP1.2Establish and maintain criteria for evaluating alternatives, and the
relative ranking of these criteria.
6.1: Actions to address risks and opportunities
The organization and scrum team must
determine the criteria for evaluating alternatives
based on Agile practices.
The organization must determine the criteria for
evaluating alternatives and rank each criteria
based on SAFe® practices.
6.3: Planning of changes
SP1.3 Identify alternative solutions to address issues.
4.3: Determining the scope of the quality
management system
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. The Scrum Master
first checks that the product/service is not
available internally before working with the
development team and Product Owner to
procure the product/service. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
Appraisal Considerations:
- In effect, this practice defines the “entry criteria” by which issues are selected for
formal evaluation, and therefore are subject to the remainder of the practices in
this PA.
- See model for typical examples where formal evaluation processes might be
useful (e.g., trade studies of equipment or software, supplier selection, tools,
make/buy decisions).
- Note that organizations may have different approaches for how the formal
evaluation processes are architected and documented. They could be embedded
within several associated processes (e.g., supplier selection process or trade
studies) rather than a separate “DAR process”. If distributed across several
processes, this may also already indicate the decision reached by the organization
as to which processes need formal evaluation techniques, rather than a separate,
integrated set of guidelines.
- Identification of the issues subject to formal evaluation (i.e., applying these
guidelines) is not explicitly addressed in other DAR SPs; therefore, it should be
considered here. An outcome of this would be the identified set of issues subject
to application of the formal evaluation process (which is detailed in the remainder
of the DAR SPs).
- There may be a variety of suitable evaluation processes that could be selected
from, as appropriate to the situation. “Formal evaluation processes can vary in
formality, type of criteria, and methods employed.” See PA introductory notes for
examples of different techniques.
Artifact Example:
- Guidelines for when to apply a formal evaluation process
- Criteria or checklists for determining when to apply a formal evaluation process
- Process description for conducting formal evaluations and selection of applicable
decision-making techniques
- Identified set of typical issues subject to a formal evaluation process
Appraisal Considerations:
- None
Artifact Example:
- Documented evaluation criteria
- Rankings of criteria importance
- Traceability of criteria to documented sources (e.g., requirements, assumptions,
business objectives)
- Guidance for determining and applying evaluation criteria (e.g., ranges, scales,
formulas, rationale)
- Rationale for selection and rejection of evaluation criteria
Appraisal Considerations:
- Additional solutions may be identified following the initial analysis or in later
phases of the life cycle
- Often the identified potential solutions and the mechanisms used to develop
them are documented in the trade study, report, or decision results
Artifact Example:
- Identified alternatives
- Results of brainstorming sessions, interviews, or other techniques used to
identify potential solutions.
- Research resources and references (e.g. literature surveys)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. DAR, Page 1
Page 10
Decision Analysis and Resolution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
6.1: Actions to address risks and opportunities
Design, implementation, and solution
alternatives are added into the Funnel phase of
the Portfolio Kanban, Value Stream Kanban,
and Program Kanban as Epics, Capabilities, or
Features, respectively.
6.3: Planning of changes
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: e) any necessary actions are taken on
problems determined during the reviews, or
verification and validation activities;
SP1.4 Select evaluation methods.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. The Scrum Master
first checks that the product/service is not
available internally before working with the
development team and Product Owner to
procure the product/service. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
Using Set-Based Design in accordance with
SAFe® Principle #3 “Assume variability,
preserve options”, alternatives can be evaluated
using their economic trade-offs by plotting them
on a spectrum with a different weight for each
alternative, or plotting them with two different
factors (such as cost and performance) to make
a trade-off curve.
Using Model-Based Systems Engineering
(MBSE) in accordance with SAFe® practices,
modeling, prototyping, and simulations can be
used to eliminate some alternatives and validate
others.
SP1.5Evaluate alternative solutions using established criteria and
methods.
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. The Scrum Master
first checks that the product/service is not
available internally before working with the
development team and Product Owner to
procure the product/service. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
4.3: Determining the scope of the quality
management system
Design, implementation, and solution
alternatives are explored during the Analysis
phase of the Portfolio Kanban, Value Stream
Kanban, and Program Kanban.
Appraisal Considerations:
- Additional solutions may be identified following the initial analysis or in later
phases of the life cycle
- Often the identified potential solutions and the mechanisms used to develop
them are documented in the trade study, report, or decision results
Artifact Example:
- Identified alternatives
- Results of brainstorming sessions, interviews, or other techniques used to
identify potential solutions.
- Research resources and references (e.g. literature surveys)
Appraisal Considerations:
- See model for example evaluation methods (e.g., simulations, engineering
studies, probabilistic models).
- The level of detail and formality of a technique may vary according to the
specifics of the issue to be resolved (e.g., cost, risk, risk, performance).
Artifact Example:
- Selected evaluation methods
- List of candidate or preferred evaluation methods.
- Guidance on selection of appropriate evaluation methods.
Appraisal Considerations:
- The evaluation results relate to application of the evaluation criteria (SP1.2)
upon the identified potential alternative solutions (SP1.3). See these SPs for
additional work products and artifacts that may help substantiate enactment of this
practice.
- The evaluation criteria, alternative solutions, and evaluation results may all be
contained in a report or study summarizing the formal evaluation (see SP1.6).
Artifact Example:
- Evaluation results
- Conclusions or findings from evaluations
- Evaluated assumptions and constraints for application of evaluation criteria or
interpretation of results (e.g., uncertainty, significance)
- Completed evaluation forms, checklists, or assigned criteria.
- Results of simulations, modeling, prototypes, pilots, life cycle cost analyses,
studies, etc., performed on potential solutions.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. DAR, Page 2
Page 11
Decision Analysis and Resolution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SP1.6 Select solutions from alternatives based on evaluation criteria.
4.3: Determining the scope of the quality
management system
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. The Scrum Master
first checks that the product/service is not
available internally before working with the
development team and Product Owner to
procure the product/service. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
The highest-priority epics/capabilities/features
that are sufficiently elaborated during the
Analysis phase of the Portfolio, Value Stream,
and Program Kanban and approved are moved
to their respective Backlogs and are moved into
Implementation phase when ready at relevant PI
Planning boundaries.
Appraisal Considerations:
- The evaluation criteria, alternative solutions, evaluation methods, and evaluation
results may all be contained in a report or study summarizing the formal evaluation
(see other SPs for additional information that might be contained in the summary
report).
Artifact Example:
- Recommended solutions to address significant issues
- Documented results and rationale of the decision
- Risk assessment of solutions or execution of the decision-making process
- Approval of the final selected solution by stakeholders
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. DAR, Page 3
Page 12
Integrated Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1
The work is conducted using a defined process that is
tailored from the organization's set of standard
processes.
SP1.1Establish and maintain the project’s defined processes from
project startup and throughout the life of the project.Appraisal Considerations:
- “The project’s defined process is a set of defined processes and subprocesses
that form an integrated, coherent lifecycle for the project.”
- The v1.1 version of the model will clarify that, for staged level 3, all staged level 2-
3 PAs must be reflected in the organization’s standard process and project’s
defined processes. In other words, for ML3, the ML2 PAs must incorporate the
ML3 GPs.
- See OPD PA for the establishment and maintenance of the organization's set of
standard processes, the library of process assets, measurement repository, life-
cycle models, and tailoring guidelines.
Artifact Example:
- The project's defined process
- Revision history for the project’s defined process.
- Organizational standard processes.
- Defined criteria (e.g., process) that describe how the project’s defined process is
to be established and maintained.
- Set of organization standard life cycle model descriptions.
- Tailoring guidelines for producing the project’s defined process.
- Set of typical tailorings for projects, e.g., application domains or lifecycles, such
as O&M, R&D, service delivery.
- Organizational asset library/repository.
- Organizational measurement database/repository.
- Approved waivers to deviations from the organization’s standard process.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process states, including applicable
design and development activities;
The Agile process (ScrumXP, Kanban) is the set
of defined processes for the project. The Scrum
Master is responsible for making sure that the
development team and the organization follow
Agile practices.
The Scaled Agile Framework (SAFe®) is the set
of defined processes for the project. The Scrum
Master is responsible for making sure that the
development team and the organization follow
Agile practices.
SP1.2Use organizational process assets and the measurement
repository for estimating and planning project activities.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
b) information derived from previous similar
design and development activities; d) standards
or codes of practices that the organization has
committed to implement;
The Product Backlog Estimate is the total
number of story points in the Product Backlog
and is used to predict project length.
Long-term estimates can be made using Epic-
level Story Point estimation, the velocity of each
ART, and an estimate of the capacity allocation
given to the project.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.1: General
Story Points estimate the value and effort for
each requirement.
Story Points estimate the value and effort for
each requirement
(Epic/Capability/Feature/Story).
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per Iteration.
SP1.3Establish and maintain the project’s work environment based on
the organization's work environment standards.
Appraisal Considerations:
- In order for the practice to be implemented, the organization must have
established and populated an organizational asset library/repository and an
organizational measurement database/repository. This need not be a single
database, but could be a set of related databases.
- See Organizational Process Definition for information on the organizational asset
library and the organization's measurement repository.
Artifact Example:
- Project estimates
- Project plans
- Organizational measurement database/repository.
- Assumptions and rationale associated with the historical data used for the
estimate.
- Organizational asset library/repository.
- Estimating tools, algorithms, and procedures.
- Operational definitions (e.g., process/criteria) for establishing and documenting
the estimates of the attributes of the work products, services and tasks.
- Bases of Estimates (BOEs).
- Project’s defined process that includes the size and complexity of tasks, services
to be delivered and work products to be produced.
- Estimation planning parameters.
- Records of independent estimation evaluations, e.g. Delphi, or multiple
estimation techniques.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. IPM, Page 1
Page 13
Integrated Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
7.1: Resources: 7.1.3: Infrastructure
Work environment standards that support Agile
processes include co-location (when possible), a
dedicated “scrum room” or “project room”, a
Kanban Board or Task Board, and collaboration
and communication software and tools.
Work environment standards that support
SAFe® ScrumXP processes include co-location
(when possible), a dedicated “scrum room” or
“project room”, a Kanban Board or Task Board,
and collaboration and communication software
and tools.
7.1: Resources: 7.1.4: Environment for the
operation of processes
SP1.4Integrate the project plan and other plans that affect the project to
describe the defined process for the project.
8.1: Operational planning and control
The Product Roadmap / Product Backlog
identifies and groups the product requirements
and prioritizes and creates high-level time
frames. It is updated throughout the project.
The SAFe® Roadmap consists of a the
upcoming planned and committed Program
Increment (PIs) and the next planned PIs, with
upcoming Milestones indicated.
8.3: Design and development of products and
services: 8.3.1: General
The Program and Value Stream Backlog
contains all of the upcoming work that affects
the Solution, including Features/Capabilities and
Enablers.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs
The Team Backlog contains all of the things that
the team needs to do to advance their part of
the work.
The Release Plan schedules the release of a
specific set of features.
The PI Planning meeting generates the PI
Objectives for the next Program Increment (PI),
as well as a “program board” for each
dependency, Milestone, and Feature/Enabler
planned for each Iteration.
The Sprint Backlog shows all of the user stories
in a sprint and related tasks.
The Iteration Backlog shows all of the user
stories committed to the Iteration and related
tasks.
The Sprint Burndown Chart shows the status of
the work that the development team has
completed.
The Team Burndown Chart or Team Kanban
shows the status of the development team's
work-in-progress (WIP).
SP1.5Manage the project using the project plan, other plans that affect
the project, and the defined process for the project.
8.1: Operational planning and control
The Product Roadmap / Product Backlog
identifies and groups the product requirements
and prioritizes and creates high-level time
frames. It is updated throughout the project.
The SAFe® Roadmap consists of a the
upcoming planned and committed Program
Increment (PIs) and the next planned PIs, with
upcoming Milestones indicated.
8.3: Design and development of products and
services: 8.3.1: General
The Program and Value Stream Backlog
contains all of the upcoming work that affects
the Solution, including Features/Capabilities and
Enablers.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls
The Release Plan schedules the release of a
specific set of features.
The PI Planning meeting generates the PI
Objectives for the next Program Increment (PI),
as well as a “program board” for each
dependency, Milestone, and Feature/Enabler
planned for each Iteration.
Appraisal Considerations:
- See model for typical subordinate plans that might be applicable.·
- A distinction between IPM and PP is that this practice expands the development
of the project plan to include additional activities such as incorporating the
Project’s Defined Process, coordinating plans with relevant stakeholders, using the
organizational process assets and incorporating plans for peer reviews, and
establishing objective entry and exit criteria.
- Many of the indirect artifacts identified above could be documented in the project
plan.
- See Project Planning PA for information about establishing and maintaining a
project plan.
Artifact Example:
- Project plan
- Subordinate plans
- Equipment and tools for the project
- Installation, operation, and maintenance manuals for the project work
environment
- User surveys and results
- Usage, performance, and maintenance records
- Support services for the project’s work environment
- Project’s defined process.
- List of relevant stakeholders.
- Project schedule and schedule dependencies.
- Databases (e.g., skills and training).
- Training plans or training that is needed to perform the project’ defined process.
- Entry and exit criteria for the tasks defined in the WBS.
- Documented system-level and project interface risks.
- Documented specifications of base and derived measures, and data collection
and storage procedures.
- Meeting minutes from stakeholder reviews of the project plan.
- Stakeholder conflict resolution procedure.
Appraisal Considerations:
- See Project Monitoring and Control process area for information about
monitoring and controlling the project. The intent of this practice is to include those
activities described in PMC.
Artifact Example:
- Integrated plans
- Work products created by performing the project's defined process
- Collected measures ("actuals") and progress records or reports]
- Revised requirements, plans, and commitments
- Integrated plans
- Project plan and subordinate plans
- Projects defined process
- Criteria or checklists used to track and manage transition across the project or
product life cycle
- Used to manage the project.
- Project entries into the organizational measurement database/repository.
- Entry and exit criteria and documented completion for the tasks defined in the
WBS.
- Records of project tracking (e.g., metrics, analyses, variance reports) against the
project’s planning parameters using documented / measurable thresholds.
- Corrective actions based on discrepancies vs. plan.
Appraisal Considerations:
- None
Artifact Example:
- Requirement list for the integrated work environment that enables collaboration
of relevant stakeholders
- Periodic evaluation sheet of the integrated work environment
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. IPM, Page 2
Page 14
Integrated Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
The Sprint Backlog shows all of the user stories
in a sprint and related tasks.
The Team Backlog contains all of the things that
the team needs to do to advance their part of
the work.
The Sprint Burndown Chart shows the status of
the work that the development team has
completed.
The Team Burndown Chart or Team Kanban
shows the status of the development team's
work-in-progress (WIP).
SP1.6 Establish and maintain teams.
8.3: Design and development of products
and services: 8.3.2: Design and
development planning: d) the
responsibilities and authorities involved in
the design and development process; f)
the need to control interfaces between
persons involved in the design and
development process;
Agile teams in Scrum consist of seven
people, plus or minus two people. This
includes the Product Owner, the Scrum
Master, and the development team.
Larger projects and development teams
are broken up into multiple scrum teams.
SAFe® defines the size and structure of
the Team, Agile Release Train, Value
Stream, and Portfolio.
The Sprint Backlog shows which team
member is responsible for a given task.
The Iteration Backlog shows which team
member is responsible for a given task.
SP1.7Contribute process related experiences to the organizational
process assets. Appraisal Considerations:
- Be careful of too little control over the asset library (anything goes in, not easy to
use) or that it is not kept up to date with documentation that reflects the current
processes.
Artifact Example:
- Proposed improvements to the organization's process assets
- Actual process and product measures collected from the project
- Documentation (e.g., exemplary process descriptions, plans, training modules,
checklists, and lessons learned)
- Project best practices and lessons learned
- Processes, procedures, and criteria for submitting improvements to the
organizations process assets.
- Organizational measurement database/repository that reflects actual process
and product and service measures from the projects.
- Organizational asset library/repository that provides evidence that work products
and lessons learned are being populated by the projects.
- Records of proposed process improvements and disposition.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: f) documented information of these
activities is retained.
Sprint Retrospective meeting minutes or action
items may be an output from the meeting.
Iteration Retrospective meeting minutes or
action items may be an output from the meeting.
SG2Coordination and collaboration of relevant stakeholders
are conducted.
SP2.1 Manage the involvement of relevant stakeholders in the work.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: d) the responsibilities and authorities
involved in the design and development
process; f) the need to control interfaces
between persons involved in the design and
development process;
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
Appraisal Considerations:
- Refer to the PP PA for more information on identifying stakeholders and planning
their appropriate involvement
- Ensure that the involvement of relevant stakeholders has been managed in such
a way that product and product component requirements, service and service
component requirements, plans, issues and risks are coordinated in a timely
manner.
- The plan for stakeholder involvement may be contained in the project plan. This
plan should contain how relevant stakeholder involvement will be managed
through project plan and subordinate plan reviews, periodic stakeholder meetings,
etc.
Artifact Example:
- Agendas and schedules for collaborative activities
- Documented issues (e.g. issues with the customer requirements, product and
product component requirements, product architecture, and product design)
- Recommendations on resolving stakeholder issues
- Documented defects, issues, and action items arising from stakeholder reviews
- Plan for stakeholder involvement
- Documented product, service and project interface risks
- Project plan, identifying relevant stakeholders
- Issues and dispositions for resolving stakeholder interfaces and
misunderstanding.
- Project schedule(s) that identify critical dependencies with relevant stakeholders.
- Milestone/stakeholder review meeting minutes.
- Organizational chart.
- Records of reviews, demonstrations or testing on work products produced by
relevant stakeholders or produced for other projects.
Appraisal Considerations:
- See Project Monitoring and Control process area for information about
monitoring and controlling the project. The intent of this practice is to include those
activities described in PMC.
Artifact Example:
- Integrated plans
- Work products created by performing the project's defined process
- Collected measures ("actuals") and progress records or reports]
- Revised requirements, plans, and commitments
- Integrated plans
- Project plan and subordinate plans
- Projects defined process
- Criteria or checklists used to track and manage transition across the project or
product life cycle
- Used to manage the project.
- Project entries into the organizational measurement database/repository.
- Entry and exit criteria and documented completion for the tasks defined in the
WBS.
- Records of project tracking (e.g., metrics, analyses, variance reports) against the
project’s planning parameters using documented / measurable thresholds.
- Corrective actions based on discrepancies vs. plan.
Appraisal Considerations:
- None
Artifact Example:
- Documented shared vision
- List of team members assigned to each integrated team
- Integrated team charters
- Periodic integrated team status reports
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. IPM, Page 3
Page 15
Integrated Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: b) reviews are conducted to evaluate
the ability of the results of design and
development to meet requirements; e) any
necessary actions are taken on problems
determined during the reviews, or verification
and validation activities;
The Sprint Review meeting solicits comments
and feedback from stakeholders on the product
created during the sprint.
The Team and System Demos solicit comments
and feedback from stakeholders on the product
created during the sprint.
SP2.2Participate with relevant stakeholders to identify, negotiate, and
track critical dependencies.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: b) reviews are conducted to evaluate
the ability of the results of design and
development to meet requirements; e) any
necessary actions are taken on problems
determined during the reviews, or verification
and validation activities;
The Scrum Master is responsible for addressing
and resolving any roadblocks or impediments
interfering with the work of the development
team.
The Scrum Master is responsible for addressing
and resolving any roadblocks or impediments
interfering with the work of the development
team.
8.3: Design and development of products and
services: 8.3.6: Design and development
changes
The Daily Stand-up Meeting addresses
completed tasks, tasks that will be done, and
any impediments.
The Daily Stand-up Meeting addresses
completed tasks, tasks that will be done, and
any impediments.
During the Management Review and Problem-
Solving phase of PI Planning, management
agrees to planning adjustments based on
scope, resource, and dependency constraints.
The Value Stream/Program Planning Board
captures and tracks the dependencies between
pieces of functionality as well as Enablers.
SP2.3 Resolve issues with relevant stakeholders.
Appraisal Considerations:
- See model for examples of coordination issues (e.g., late commitments,
requirements/design defects, resources).
Artifact Example:
- Relevant stakeholder coordination issues
- Status of relevant stakeholder coordination issues
- Documented stakeholder coordination issues
- Reviews, reports, or briefings communicating issues to stakeholders
- Issue tracking database with evidence of issues status being tracked and issues
being resolved
- Evidence of escalation of issues to managers as needed. Could be through
stakeholder meeting minutes with subsequent project status reports documenting
issues.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: e) any necessary actions are taken on
problems determined during the reviews, or
verification and validation activities;
The Scrum Master is responsible for addressing
and resolving any roadblocks or impediments
interfering with the work of the development
team.
The Scrum Master is responsible for addressing
and resolving any roadblocks or impediments
interfering with the work of the development
team.
Appraisal Considerations:
- Refer to the PP PA for more information on identifying stakeholders and planning
their appropriate involvement
- Ensure that the involvement of relevant stakeholders has been managed in such
a way that product and product component requirements, service and service
component requirements, plans, issues and risks are coordinated in a timely
manner.
- The plan for stakeholder involvement may be contained in the project plan. This
plan should contain how relevant stakeholder involvement will be managed
through project plan and subordinate plan reviews, periodic stakeholder meetings,
etc.
Artifact Example:
- Agendas and schedules for collaborative activities
- Documented issues (e.g. issues with the customer requirements, product and
product component requirements, product architecture, and product design)
- Recommendations on resolving stakeholder issues
- Documented defects, issues, and action items arising from stakeholder reviews
- Plan for stakeholder involvement
- Documented product, service and project interface risks
- Project plan, identifying relevant stakeholders
- Issues and dispositions for resolving stakeholder interfaces and
misunderstanding.
- Project schedule(s) that identify critical dependencies with relevant stakeholders.
- Milestone/stakeholder review meeting minutes.
- Organizational chart.
- Records of reviews, demonstrations or testing on work products produced by
relevant stakeholders or produced for other projects.
Appraisal Considerations:
- See model for typical contents of documented commitments (e.g., what, who,
when, how)
- It should be noted whether or not if relevant stakeholders identified in the project
plan participate in project plan and subordinate plan reviews.
Artifact Example:
- Defects, issues, and action items resulting from reviews with relevant
stakeholders
- Critical dependencies
- Commitments to address critical dependencies
- Status of critical dependencies
- Agendas and schedules for collaborative activities
- Defects, issues, and action items arising from stakeholder reviews
- Project plan, identifying relevant stakeholders
- Projects defined process for identifying, negotiating, and tracking critical
dependencies
- Project schedule(s) that identify critical dependencies with relevant stakeholders.
- Stakeholder milestone/project status reviews
- Updated project plans reflecting and associated artifacts demonstrating
negotiating and tracking.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. IPM, Page 4
Page 16
Measurement and Analysis
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Measurement objectives and activities are aligned with
identified information needs and objectives.
SP1.1Establish and maintain measurement objectives derived from
identified information needs and objectives.
6.2: Quality objectives and planning to achieve
them: 6.2.1: b) be measurable;
The organization and scrum team must
determine their information needs and
objectives and implement a process for
collecting that information based on Agile
practices.
The organization and scrum team must
determine their information needs and
objectives and implement a process for
collecting that information based on SAFe®
practices.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: a) calibrated or verified, or both, at
specified intervals, or prior to use, against
measurement standards traceable to
international or national measurement
standards; when no such standards exist, the
basis used for calibration or verification shall be
retained as documented information;
The organization must determine and agree
upon which Metrics to use to measure their
quality and process performance, such as
program velocity, number of stories planned and
number of stories accepted, the number of
defects, and the unit test coverage percentage.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: a) what needs to be
monitored and measured;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation
SP1.2 Specify measures to address measurement objectives.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: a) calibrated or verified, or both, at
specified intervals, or prior to use, against
measurement standards traceable to
international or national measurement
standards; when no such standards exist, the
basis used for calibration or verification shall be
retained as documented information;
The process of creating estimates of the value
and effort for Story Points and refining those
estimates (such as Estimation Poker or Affinity
Estimating) should be agreed on by the scrum
team and documented or recorded as the
process for estimating User Stories.
The process of creating estimates of the value
and effort for Story Points and refining those
estimates (such as Estimation Poker or Affinity
Estimating) should be agreed on by the scrum
team and documented or recorded as the
process for estimating User Stories.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: b) the methods for
monitoring, measurement, analysis and
evaluation needed to ensure valid results;
A “benchmark” requirement is scored for effort
and value in order to determine the scores of
other requirements relative to that benchmark
requirement to estimate and prioritize User
Stories.
A “benchmark” requirement is scored for effort
and value in order to determine the scores of
other requirements relative to that benchmark
requirement to estimate and prioritize User
Stories.
The frequency of how often the scrum team
meets the sprint goals set for each sprint may
be tracked.
The frequency of how often the Team meets the
Iteration Goals set for each Iteration may be
tracked.
The number of defects found in the product,
whether build defects found in testing, defects
found by the Product Owner in User Acceptance
Testing, or defects found after product release,
can be used to track the quality of the product.
The number of defects found in the product,
whether build defects found in testing, defects
found by the Product Owner in User Acceptance
Testing, or defects found after product release,
can be used to track the quality of the product.
Appraisal Considerations:
- · It is likely that operational definitions of measures will be expanded and used to
satisfy several SPs; e.g. not only definitions, but data collection source, alignment
to information needs, analysis and reporting procedures, etc.
- The distinction between base and derived measures is significant from an
appraisal point of view only in that clear direction is provided to providers and
users on the data to be collected, generated, analyzed, etc.
- The role of the appraisal team is not to judge the sufficiency of the measurement
set itself, but rather to judge that the organization / project has thoughtfully
identified measures that meet its needs; the measures are adequately defined to
be understandable and repeatable; and that these definitions are consistently
used and institutionalized.
Artifact Example:
- documented specifications of base and derived measures
- Linkage between measures and project /service / organization measurement
objectives and information needs
- Algorithms, templates, checklists, procedures, ways of consistently collecting and
recording measures for the product, project and process attributes identified.
- Evidence of review of proposed specifications with stakeholders and other end
users
- List of prioritized measures.
Appraisal Considerations:
- The key concept is to “maintain” the alignment of measurement objectives as the
information needs evolve over time. This could be performed on an annual basis,
or otherwise
- SPs in the MA PA are fairly low level and atomic, relative to other PAs. This puts
additional burden on the appraisal team to ensure sufficient data and indicators
are collected at the practice level, distinct from other practices. It may be difficult
to distinguish objective indicators for this PA at the project/organization level on a
practice basis; e.g., a single indicator may be used to support implementation of
multiple practices. This may also put greater emphasis on interviews as a source
of implementation indicators and objective evidence
- Consider the project focus vs. organization focus when assessing this SP at
ML2/CL2 vs. ML3/CL3
Artifact Example:
- Documented measurement objectives
- Revisions to measurement objectives
- Alignment between business goals, measurement objectives/goals, information
needs/objectives (questions)
- Identified information needs and objectives
- Documented sources of information needs (see model, e.g., strategic plans,
process improvement plans, management interviews)
- Reviews of measurement objectives with affected stakeholders (e.g.,
management, providers, users).
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. MA, Page 1
Page 17
Measurement and Analysis
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
The total length of the project or the Time to
Market (the length of time until the product first
creates value and the time in between value-
generating product releases) may be measured
to track efficiency.
The amount of value generated by the product
after release (whether generating income or
generating value internally) may be tracked to
measure ROI.
The amount of value generated by the product
after release (whether generating income or
generating value internally) may be tracked to
measure ROI.
The total cost of the project may be tracked to
determine future budgets.
The total cost of the project may be tracked to
determine future budgets.
Customer satisfaction surveys can be used to
determine if the project or processes should be
adjusted.
Customer satisfaction surveys can be used to
determine if the project or processes should be
adjusted.
Scrum team satisfaction surveys and company
turnover rates (organization or scrum team) may
be used to track employee morale and behavior.
Team satisfaction surveys and company
turnover rates (organization or Agile team) may
be used to track employee morale and behavior.
During the PI (Program Increment) Inspect &
Adapt workshop, the teams review the
quantitative Metrics they have agreed to collect
to create their Program Performance Metrics,
and use the Program Predictability Measure to
determine the actual business value achieved
against the planned business value for each
team’s PI Objectives.
The Value Stream Performance Metrics and the
Value Stream Predictability Measure are created
by aggregating the Program Performance
Metrics and the Program Predictability
Measures of each ART in the Value Stream.
The Portfolio Performance Metrics are created
by aggregating the Value Stream Performance
Metrics of each Value Stream in the Portfolio.
An ART operating within 100% and 80% of their
achievement of business objectives per
Program Increment (PI) as measured by the
Program Predictability Measure is ideal in
SAFe® to allow the organization and outside
stakeholders to plan effectively.
Epic burn-up chart
Feature progress report
Cumulative flow diagram (cfd)
PI burndown chart
SP1.3 Specify how measurement data are obtained and stored.
Appraisal Considerations:
- · It is likely that operational definitions of measures will be expanded and used to
satisfy several SPs; e.g. not only definitions, but data collection source, alignment
to information needs, analysis and reporting procedures, etc.
- The distinction between base and derived measures is significant from an
appraisal point of view only in that clear direction is provided to providers and
users on the data to be collected, generated, analyzed, etc.
- The role of the appraisal team is not to judge the sufficiency of the measurement
set itself, but rather to judge that the organization / project has thoughtfully
identified measures that meet its needs; the measures are adequately defined to
be understandable and repeatable; and that these definitions are consistently
used and institutionalized.
Artifact Example:
- documented specifications of base and derived measures
- Linkage between measures and project /service / organization measurement
objectives and information needs
- Algorithms, templates, checklists, procedures, ways of consistently collecting and
recording measures for the product, project and process attributes identified.
- Evidence of review of proposed specifications with stakeholders and other end
users
- List of prioritized measures.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. MA, Page 2
Page 18
Measurement and Analysis
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.1: General
The development team collaborates to create
the Sprint Backlog and Burndown Chart, and
they are responsible for updating it at the end of
each day with which tasks were completed and
how much work time remains on new tasks that
have been started.
The development team collaborates to create
the Iteration Backlog and Burndown Chart (or
other tracking tool), and they are responsible for
updating it at the end of each day with which
tasks were completed and how much work time
remains on new tasks that have been started.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General
The scrum team should determine what to use
to keep records of measurements (which
software tool).
The scrum team should determine what to use
to keep records of measurements (which
software tool).
SP1.4 Specify how measurement data are analyzed and communicated.
Appraisal Considerations:
- (see MA.SP1.2)
- See model for description of typical contents and coverage of data analysis
procedures (e.g., methods, tools, statistics).
Artifact Example:
- Documented analysis specification and procedures
- Data analysis tools
- Explicit analysis descriptions, including who (responsibilities), how (procedures
and tools), when (frequency), where (repository), and how the results will be used.
- Data analysis tools
- Results of data analyses (e.g., graphs, reports)
- Alignment of data analyses with measurement objectives (e.g., traceability to
information needs and decision making)
- Evidence of evaluations or meetings held to review measurement analyses
(minutes, action items, etc.)
- Criteria for evaluating the utility of measurement and analysis data
- Revisions to measures and measurement objectives.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: d) when the results
from monitoring and measurement shall be
analysed and evaluated.
The scrum team should agree to follow
ScrumXP practices of displaying Burndown
Charts and Task Boards using an Information
Radiator, and determine any other data that
should be displayed on the Information Radiator
such as Kanban Boards, white boards, bulletin
boards, and any other information displays.
During Iteration Execution, Teams use a Big
Visible Information Radiator (BVIR) such as
Kanban boards or story boards to track the
status of Stories, defects, and other activities
being worked on during the Iteration.
SG2Measurement results, which address identified
information needs and objectives, are provided.SP2.1 Obtain specified measurement data.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: b) identified in order to determine
their status;
Story Points estimate the value and effort for
each requirement. The development team
estimates User Stories (or Themes, Features,
etc.) with assistance from the Product Owner.
Story Points estimate the value and effort for
each requirement. The development team
estimates User Stories (or Themes, Features,
etc.) with assistance from the Product Owner.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
The development team collaborates to create
the Sprint Backlog and Burndown Chart, and
they are responsible for updating it at the end of
each day with which tasks were completed and
how much work time remains on new tasks that
have been started.
The development team collaborates to create
the Iteration Backlog and Burndown Chart (or
other tracking tool), and they are responsible for
updating it at the end of each day with which
tasks were completed and how much work time
remains on new tasks that have been started.
SP2.2 Analyze and interpret measurement data.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: b) identified in order to determine
their status;
The total number of Story Points in the Product
Backlog creates the Product Backlog Estimate,
which is used to estimate the length and cost of
the project.
The total number of Story Points in the Product
Backlog creates the Product Backlog Estimate,
which is used to estimate the length and cost of
the project.
Appraisal Considerations:
- The analysis should be performed according to the analysis specification
described in SP1.4
Artifact Example:
- Analysis results (e.g., graphs, reports) and conclusions (preliminary or final).
- Analysis results and draft reports
- Representations for analysis results (e.g., tables, charts, histograms)
- Evidence of evaluations or meetings held to review measurement analyses
(briefings, minutes, action items, etc.)
- Follow-up analyses performed to address areas of concern, if necessary
- Revisions of criteria for future analysis.
Appraisal Considerations:
- (see MA.SP1.2 and SP1.3)
- Data should be collected according to the procedures defined in SP1.2 and
SP1.3
Artifact Example:
- Base and derived measurement data sets
- Results of data integrity tests
- Raw data collected, time tagged, and stored in accordance with defined data
collection procedures (see SP1.3)
- Derived measures calculated from collected base measures
- Results of data integrity tests
- Measurement repository populated with the specified measures
- Analysis reports and trending indicating completeness of collected data
- Results of integrity checks (e.g., tools, forms, reviews); reports of invalid or
discarded data.
Appraisal Considerations:
- see MA.SP1.2
Artifact Example:
- Data collection and storage procedures
- Explicit data collection descriptions, including who (responsibilities), how
(procedures and tools), when (frequency), where (repository).
- Data collection tools
- Data collection mechanisms and supporting tools (automatic or manual)
- Raw data collected, time tagged, and stored
- Analysis reports and trending indicating completeness of collected data
- Measurement repository
- Reports of invalid or discarded data.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. MA, Page 3
Page 19
Measurement and Analysis
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
The Sprint Retrospective may discuss the
results of the sprint using the Burndown Chart to
compare the amount of work planned with the
amount of work actually completed.
The Iteration Retrospective may discuss the
results of the Iteration using the Burndown Chart
or other tools to compare the amount of work
planned with the amount of work actually
completed.
SP2.3Manage and store measurement data, measurement
specifications, and analysis results.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: b) identified in order to determine
their status; c) SAFe®guarded from
adjustments, damage or deterioration that would
invalidate the calibration status and subsequent
measurement results.
The scrum team should keep records of
measurements according to the process they
created for storing measurements (SP 1.3).
The scrum team should keep records of
measurements according to the process they
created for storing measurements (SP 1.3).
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
SP2.4Communicate results of measurement and analysis activities to all
relevant stakeholders.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: b) identified in order to determine
their status;
The Sprint Burndown Chart shows the status of
the work that the development team has
completed and tracks actual progress to the
estimated schedule.
The Burndown Chart (or other tracking tool)
shows the status of the work that the
development team has completed and tracks
actual progress to the estimated schedule.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
The Task Board shows which user stories and
tasks are ready to do, are in progress, are ready
to be accepted, and are done.
The Kanban board/story board shows the status
of stories and tasks being worked on by the
development team.
The Sprint Retrospective may discuss the
results of the sprint using the Burndown Chart to
compare the amount of work planned with the
amount of work actually completed.
The Iteration Retrospective may discuss the
results of the Iteration using the Burndown Chart
or other tools to compare the amount of work
planned with the amount of work actually
completed.
During the PI (Program Increment) System
Demo, the business owners, customers, Agile
Teams, and other stakeholders collaboratively
rate the actual business value of each Team's
PI Objectives.
Appraisal Considerations:
- The analysis should be performed according to the analysis specification
described in SP1.4
Artifact Example:
- Analysis results (e.g., graphs, reports) and conclusions (preliminary or final).
- Analysis results and draft reports
- Representations for analysis results (e.g., tables, charts, histograms)
- Evidence of evaluations or meetings held to review measurement analyses
(briefings, minutes, action items, etc.)
- Follow-up analyses performed to address areas of concern, if necessary
- Revisions of criteria for future analysis.
Appraisal Considerations:
- See model for typical contents of measurement data stored and available for
future use; e.g., plans, measures, analyses, presentations, contextual information
- This SP is strongly linked with OPD.SP2.1, which provides detailed information
regarding an organizational measurement repository. Initially, the MA PA is
targeted at the project level. Definition and use of these repositories may vary with
the organization.
Artifact Example:
- Stored data inventory
- Measurement repository with historical data and results.
- Contextual information for understanding and interpreting the measures, and
assessing them for reasonableness and applicability
- Measurement repository, with access restriction to the stored data
Appraisal Considerations:
- None
Artifact Example:
- Delivered reports and related analysis results
- Contextual information or guidance to aid in the interpretation of analysis results
- Contextual data or guidance to aid in interpretation of analysis results
- Presentations of data analyses and reports
- Measurement indicator templates
- Distribution lists or web pages for communicating measurement results
- Alignment maintained between measures, analyses, and business objectives.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. MA, Page 4
Page 20
Organizational Process Definition
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1A set of organizational process assets is established and
maintained.
SP1.1Establish and maintain the organization's set of standard
processes.
4.4.1: Quality management system and its
processes
All Agile ceremonies need to be defined for the
“who, what, when, where, why” - how the
organization and scrum team performs Agile
ceremonies and what tools and techniques they
use such as Definition of Done, Story Point
estimation techniques, roles and
responsibilities, and required training.
6.1: Actions to address risks and opportunities:
6.1.2: b) how to: 1) integrate and implement the
actions into its quality management system
processes;
“The Scaled Agile Framework (SAFe®) is a
freely revealed knowledge base of proven,
integrated patterns for enterprise-scale Lean-
Agile development. It is scalable and modular,
allowing each organization to apply it in a way
that provides better business outcomes and
happier, more engaged employees.”
Organizations must create a strategic plan to
implement SAFe® and to maintain adherence to
SAFe® practices and processes.
SP1.2Establish and maintain descriptions of lifecycle models approved
for use in the organization.
4.4.1: Quality management system and its
processes: a) determine the inputs required and
the outputs expected from these processes; b)
determine the sequence and interaction of these
processes;
The organization and scrum team must define
the specific process for each Agile ceremony
such as sprint length, how to estimate Story
Points, how to update the Sprint/Program
Backlog, how to perform Automated Testing,
and all other processes needed to implement
Agile.
8.1: Operational planning and control: d)
implementing control of the processes in
accordance with the criteria;
“The Scaled Agile Framework (SAFe®) is a
freely revealed knowledge base of proven,
integrated patterns for enterprise-scale Lean-
Agile development. It is scalable and modular,
allowing each organization to apply it in a way
that provides better business outcomes and
happier, more engaged employees.”
Organizations using SAFe® must ensure that
their employees and projects are operating
under SAFe® practices and processes.
8.3: Design and development of products and
services: 8.3.1: General
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: b) the required process stages,
including applicable design and development
reviews;
SP1.3Establish and maintain tailoring criteria and guidelines for the
organization's set of standard processes.
Appraisal Considerations:
- See model for a description of the typical contents of a set of standard process
assets (e.g., process descriptions, life cycle models, tailoring guidelines, process-
related documentation).
- “The organization’s set of standard processes may include multiple process
architectures and standard processes.”
- “The organization’s set of standard processes typically includes technical,
management, administrative, support, and organizational processes.”
Artifact Example:
- Organization's set of standard processes
- Revisions to the organization’s set of standard processes (e.g., revised
processes, reviews, etc.)
- Process architectures describing relationships among process elements
- Process element attributes (e.g., inputs, outputs, entry/exit criteria, roles,
interfaces).
- Templates and descriptions for process assets
- Process and product standards
- Process for development, review, and revision of organizational standard
processes and assets
- Results of peer reviews of the organization’s set of standard processes
Appraisal Considerations:
- Look for the synergy between the life cycle models used across disciplines being
assessed (e.g. product life cycle, project life cycle, software vs. systems life
cycles). For example, consider such life cycle phases as concept exploration,
development, transition, retirement, etc.
Artifact Example:
- Descriptions of life-cycle models
- Revisions to the organization’s set of life-cycle process models (e.g., revised
models, reviews, etc.)
- Guidance and criteria on selection of life-cycle models based on project
characteristics.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPD, Page 1
Page 21
Organizational Process Definition
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
6.3: Planning of changes
The organization and scrum team must define
what ceremonies and/or processes are
tailorable and not tailorable. The scrum team
(including the customer) must agree upon any
tailoring needed for the processes of a project.
Organizations using SAFe® may tailor SAFe®
practices to accommodate their needs so long
as it is implemented in a way that follows
SAFe® principles.
SP1.4 Establish and maintain the organization's measurement repository.
Appraisal Considerations:
- Refer to the MA PA for information regarding definition, collection, and analysis
of measures.
- The organizational repository should contain both product and process
measures.
- The processes and mechanism should ensure consistency of collected measures
for comparison (i.e., apples to apples).
Artifact Example:
- Definition of the common set of product and process measures for the
organization's set of standard processes
- Organization's measurement repository (i.e., the repository structure and support
environment)
- Organizational measurement data
- Revisions to the organization’s measurement repository (e.g., revised measures,
collected measures, reviews, etc.)
- Analyses / rationale supporting definition of measures related to products and
organization standard process (elements).
- Procedures for collection, storage, analysis of organizational measures.
- Logs or records indication population and use of measurement repository.
4.4.1: Quality management system and its
processes: c) determine and apply the criteria
and methods (including monitoring,
measurements and related performance
indicators) needed to ensure the effective
operation and control of these processes;
The organization and scrum team must define
how measurements will be captured and kept,
using such things as information radiators, code
repositories, and other measurement
repositories.
The Team/Agile Release Train (ART)/Value
Stream/Portfolio must agree upon and define
how measurements will be captured and kept,
using such things as information radiators, code
repositories, and other measurement
repositories.
SP1.5 Establish and maintain the organization's process asset library.
Appraisal Considerations:
- This is often called a Process Asset Library (PAL).
- See model for typical examples of process-related documentation that is
provided in the library (e.g., policies, processes, procedures, work aids, checklists,
templates, tailoring guidance, sample plans).
Artifact Example:
- Organization's library to store the process-related documentation (i.e., the library
structure and support environment)
- Process Asset Library (PAL)
- Revisions to the organization’s library of process-related assets (e.g., revised
library and assets, reviews, etc.)
- Best examples of process-related documentation items
- Collection of best practices
- Catalog of process documentation items
- Criteria for adding items to library
8.1: Operational planning and control: d)
implementing control of the processes in
accordance with the criteria;
The organization and scrum team must define
what tools will be used as the organization’s
process asset library and how it will be used.
Most Agile tools provide the framework for the
processes used for Agile ceremonies.
The Team/Agile Release Train (ART)/Value
Stream/Portfolio must agree upon and define
what tools will be used as the organization’s
process asset library and how it will be used.
Most Agile tools provide the framework for the
processes used for SAFe® practices.
SP1.6 Establish and maintain work environment standards.
Appraisal Considerations:
- See model for a description of what is typically included in tailoring guidelines
(e.g., mandatory vs. optional activities, options, tailoring procedures).
Artifact Example:
- Tailoring criteria and guidelines for the organization's set of standard processes
- Revisions to the organization’s tailoring criteria and guidelines (e.g., revised
guidelines, reviews, etc.)
- Project Defined Processes· Guidelines, and standards for documenting the
defined processes.
- Process compliance review checklists.
- Waiver processes, forms, and criteria.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPD, Page 2
Page 22
Organizational Process Definition
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Appraisal Considerations:
- None
Artifact Example:
- Work environment standards
- Procedures for operation, safety, and security of the work environment
- Standard workstation hardware and software
- Standard application software and tailoring guidelines for it
- Standard production and calibration equipment
- Process for requesting and approving tailoring or waivers
7.1: Resources: 7.1.4: Environment for the
operation of processes
The organization and scrum team must define
the work environment standards in accordance
with Agile principles such as development tools,
testing tools, communication tools, and any
other environmental standards or tools needed.
The Team/Agile Release Train (ART)/Value
Stream/Portfolio must agree upon and define
the work environment standards in accordance
with SAFe® principles such as development
tools, testing tools, communication tools, and
any other environmental standards or tools
needed.
SP1.7Establish and maintain organizational rules and guidelines for the structure,
formation, and operation of teams.
Appraisal Considerations:
- None
Artifact Example:
Rules and guidelines for structuring and forming integrated teams
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: d) the responsibilities and authorities
involved in the design and development
process; f) the need to control interfaces
between persons involved in the design and
development process;
The organization and scrum team must define
the roles and responsibilities of the scrum team
such as the Product Owner and Scrum Master,
and the operation of the scrum teams such as
Automated Testing and Daily Scrum
ceremonies.
The organization must define the roles and
responsibilities of each role in each level of
SAFe®, and the operation of the Teams, ARTs,
and Value Streams.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPD, Page 3
Page 23
Organizational Process Focus
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1
Strengths, weaknesses, and improvement opportunities
for the organization's processes are identified
periodically and as needed.
SP1.1Establish and maintain the description of process needs and
objectives for the organization.
4.1: Understanding the organization and its
context
All Agile ceremonies and tools (ScrumXP,
Kanban, SAFe®) used by the organization must
be defined and agreed-upon and available to
members of the organization.
4.4: Quality management system and its
processes
The scrum team defines and agrees upon a
Definition of Done to use to determine that a
requirement has been completed.
5.1: Leadership and commitment: 5.1.1:
General: b) ensuring that the quality policy and
quality objectives are established for the quality
management system and are compatible with
the context and strategic direction of the
organization;
The process of creating estimates of the value
and effort for Story Points and refining those
estimates (such as Estimation Poker or Affinity
Estimating) should be agreed on by the scrum
team and documented or recorded as the
process for estimating User Stories.
5.2: Policy: 5.2.1: Establishing the quality policy:
a) is appropriate to the purpose and context of
the organization and supports its strategic
direction; b) provides a framework for setting
quality objectives;
The Sprint Retrospective meeting discusses
what processes went well and what did not in
the sprint, and what changes could be made to
improve the next sprint, involving the Product
Owner, Scrum Master, and development team.
The Iteration Retrospective evaluates what went
well and what did not go well in the last sprint,
and what they can change to improve the next
Iteration.
6.2: Quality objectives and planning to achieve
them: 6.2.1: a) be consistent with the quality
policy;
6.2: Quality objectives and planning to achieve
them: 6.2.2: a) what will be done;
8.1: Operational planning and control: d)
implementing control of the processes in
accordance with the criteria;
10.1: General
SP1.2Appraise the organization's processes periodically and as needed
to maintain an understanding of their strengths and weaknesses.
4.1: Understanding the organization and its
context
The Sprint Retrospective meeting discusses
what processes went well and what did not in
the sprint, and what changes could be made to
improve the next sprint, involving the Product
Owner, Scrum Master, and development team.
The Iteration Retrospective evaluates what went
well and what did not go well in the last sprint,
and what they can change to improve the next
Iteration.
4.4: Quality management system and its
processes: 4.4.1: f) address the risks and
opportunities as determined in accordance with
the requirements of 6.1;
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
Appraisal Considerations:
- The organization’s annual report or strategic plan may be a source for obtaining
the organization business goals.
Artifact Examples:
- Organization’s process needs and objectives
- Revisions to the organization’s process and objectives (e.g., revised objectives,
reviews, etc.)
- Organizational business needs, objectives, and constraints
- Organizational process performance objectives (e.g., time to market, product
quality, productivity)
- Process and product standards and guidelines (notation, level of detail, etc.)
- Characterization of current organization processes
Appraisal Considerations:
- None
Artifact Examples:
- Assessment findings that address strengths and weaknesses of the
organization's processes
- Plans for the organization's process assessments
- Improvement recommendations for the organization's processes
- Assessment records or reports (plan, scope, participants, interview schedules,
list of artifacts examined, etc.)
- Process improvement progress records (e.g., metrics, trends, analyses)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPF, Page 1
Page 24
Organizational Process Focus
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
6.1: Actions to address risks and opportunities:
6.1.1
7.1: Resources: 7.1.3: Infrastructure
10.1: General
SP1.3Identify improvements to the organization's processes and
process assets.
4.4: Quality management system and its
processes
The Sprint Retrospective meeting discusses
what processes went well and what did not in
the sprint, and what changes could be made to
improve the next sprint, involving the Product
Owner, Scrum Master, and development team.
The Iteration Retrospective evaluates what went
well and what did not go well in the last Iteration,
and what they can change to improve the next
Iteration.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
The PI (Program Increment) Planning
Retrospective captures what went well, what
didn’t and what could be done better for the next
PI .
5.3: Organizational roles, responsibilities, and
authorities: c) reporting on the performance of
the quality management system and on
opportunities for improvement, in particular to
top management;
The Post- PI (Program Increment) Planning
Retrospective captures what went well, what
didn’t and what could be done better for the next
PI (for multi-ART Value Streams).
6.1: Actions to address risks and opportunities:
6.1.1
6.3: Planning of changes: a) the purpose of the
changes and their potential consequences;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation
10.1: General
10.3: Continual improvement
SG2
Process actions that address improvements to the
organization's processes and process assets are planned
and implemented.
SP2.1Establish and maintain process action plans to address
improvements to the organization's processes and process assets.
4.4: Quality management system and its
processes
The Sprint Retrospective meeting may generate
action items to improve for the next sprint.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
Appraisal Considerations:
- See model for typical contents of process action plans (e.g., infrastructure,
procedures, responsibilities, resources, schedules).
Artifact Examples:
- Organization's approved process action plans
- Review and revision of the organization’s approved process action plans (e.g.,
revised objectives, reviews, etc.)
- Strategies for implementation of improvements
- Documented infrastructure for process improvement with roles and
responsibilities (e.g., management, process owners, process group, action teams,
practitioners)
- Results of stakeholder reviews of process action plans
- Revised action plans
- Piloting of proposed process improvements
Appraisal Considerations:
- None
Artifact Examples:
- Assessment findings that address strengths and weaknesses of the
organization's processes
- Plans for the organization's process assessments
- Improvement recommendations for the organization's processes
- Assessment records or reports (plan, scope, participants, interview schedules,
list of artifacts examined, etc.)
- Process improvement progress records (e.g., metrics, trends, analyses)
Appraisal Considerations:
- Improvements may be captured in a variety of mechanisms; e.g. action plans,
change requests, process improvement proposals, process assessment reports.
- Look for a list of candidate process improvement ideas, and also the set that
were selected for action. These lists should be maintained over time.
Artifact Examples:
- Analysis of candidate process improvements
- Identification of improvements for the organization's processes
- Prioritized list of planned process improvements
- Measurements and analysis of processes
- Reports of process performance
- Reviews of lessons learned
- Meeting minutes from process improvement related reviews and planning
sessions
- Documented criteria for prioritization of improvement opportunities
- Change request and control process (e.g., CCB) for review and disposition of
improvement proposals
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPF, Page 2
Page 25
Organizational Process Focus
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
6.1: Actions to address risks and opportunities:
6.1.2: a) actions to address these risks and
opportunities; b) how to : 1) integrate and
implement the actions into its quality
management system processes;
6.3: Planning of changes: a) the purpose of the
changes and their potential consequences;
8.1: Operational planning and control: d)
implementing control of the processes in
accordance with the criteria;
10.1: General
SP2.2 Implement process action plans.
4.4: Quality management system and its
processes: 4.4.1
The Sprint Retrospective meeting may generate
action items to improve for the next sprint.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
The Agile approach of inspecting and adapting
processes means that action items
implemented from the Sprint Retrospective
meeting should be evaluated for their effect on
process performance.
8.1: Operational planning and control: d)
implementing control of the processes in
accordance with the criteria;
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
10.1: General
SG3
Organizational process assets are deployed across the
organization and process-related experiences are
incorporated into organizational process assets.
SP3.1 Deploy organizational process assets across the organization.
4.4: Quality management system and its
processes: 4.4.1
All Agile ceremonies and tools (ScrumXP,
Kanban, SAFe®) used by the organization must
be defined and agreed-upon and available to
members of the organization.
5.1: Leadership and commitment: 5.1.1:
General: c) ensuring the integration of the
quality management system requirements into
the organization's business processes; d)
promoting the use of the process approach and
risk-based thinking; f) communicating the
importance of effective quality management and
of conforming to the quality management
system requirements;
IP (Innovation and Planning) Iterations can be
used to deploy new process assets across the
organization.
7.1: Resources: 7.1.3: Infrastructure
Appraisal Considerations:
- See model for typical contents of process action plans (e.g., infrastructure,
procedures, responsibilities, resources, schedules).
Artifact Examples:
- Organization's approved process action plans
- Review and revision of the organization’s approved process action plans (e.g.,
revised objectives, reviews, etc.)
- Strategies for implementation of improvements
- Documented infrastructure for process improvement with roles and
responsibilities (e.g., management, process owners, process group, action teams,
practitioners)
- Results of stakeholder reviews of process action plans
- Revised action plans
- Piloting of proposed process improvements
Appraisal Considerations:
- None
Artifact Examples:
- Status and results of implementing process action plans
- Commitments among the various process action teams
- Negotiated commitments and revisions to process action plans
- Plans for pilots
- Process improvement status reviews and briefings (management reviews,
technical reviews)
- Records of effort and expenditure associated with implementation (e.g., metrics,
analyses, progress reports)
- Issues identified from implementation of process action plans
- Implementation issue identification and resolution records
- Alignment of process improvements with organizational objectives
Appraisal Considerations:
- The deployment plan typically includes such items as assets to be deployed,
schedules, resources, scope of the deployment, training, support tools, etc.
Artifact Examples:
- Plans for deploying organizational process assets and changes to them across
the organization
- Training materials for deploying organizational process assets and changes to
them
- Documentation of changes to organizational process assets
- Support materials for deploying organizational process assets and changes to
them
- Training materials for deploying the process assets and changes to process
assets
- Support materials for deploying the process assets and changes to process
assets
- Process asset library (PAL)
- Records of effort and expenditure associated with deployment
- Deployment issue identification and resolution records
- Records of training or orientation provided on the new process assetsLast updated 8/20/17
This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPF, Page 3
Page 26
Organizational Process Focus
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
7.1: Resources: 7.1.4: Environment for the
operation of processes
10.1: General
SP3.2
Deploy the organization's set of standard processes to projects at
their startup and deploy changes to them as appropriate
throughout the life of each project.
4.4: Quality management system and its
processes: 4.4.1
All Agile ceremonies and tools (ScrumXP,
Kanban, SAFe®) used by the organization must
be defined and agreed-upon and available to
members of the organization.
5.1: Leadership and commitment: 5.1.1:
General: c) ensuring the integration of the
quality management system requirements into
the organization's business processes; g)
ensuring the quality management system
achieves its intended results; h) engaging,
directing, and supporting persons to contribute
to the effectiveness of the quality management
system; j) supporting other relevant
management roles to demonstrate their
leadership as it applies to their areas of
responsibility.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
5.3: Organization roles, responsibilities and
authorities: e) ensuring that the integrity of the
quality management system is maintained when
changes to the quality management system are
planned and implemented.
6.3: Planning of changes: a) the purpose of the
changes and their potential consequences;
7.1: Resources: 7.1.3: Infrastructure
7.1: Resources: 7.1.4: Environment for the
operation of processes
10.1: General
SP3.3Monitor the implementation of the organization's set of standard
processes and use of process assets on all projects.
4.1: Understanding the organization and its
context
The Sprint Retrospective meeting discusses
what processes went well and what did not in
the sprint, and what changes could be made to
improve the next sprint, involving the Product
Owner, Scrum Master, and development team.
4.4: Quality management system and its
processes: 4.4.1
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
Appraisal Considerations:
- The deployment plan typically includes such items as assets to be deployed,
schedules, resources, scope of the deployment, training, support tools, etc.
Artifact Examples:
- Organization's list of projects and status of process deployment on each project
(i.e., existing and planned projects)
- Guidelines for deploying the organization’s set of standard processes on new
projects
- Records of tailoring the organization’s set of standard processes and
implementing them on identified projects
- Training materials for deploying the process assets and changes to process
assets
- Support materials for deploying the process assets and changes to process
assets
- Process asset library (PAL)
- Records of effort and expenditure associated with deployment
- Deployment issue identification and resolution records
- Records of training or orientation provided on the new process assets
Appraisal Considerations:
- The deployment plan typically includes such items as assets to be deployed,
schedules, resources, scope of the deployment, training, support tools, etc.
Artifact Examples:
- Plans for deploying the process assets and changes to process assets
- Documentation of changes to the process assets
- Generated process assets, methods, and tools
- Training materials for deploying the process assets and changes to process
assets
- Support materials for deploying the process assets and changes to process
assets
- Process asset library (PAL)
- Records of effort and expenditure associated with deployment
- Deployment issue identification and resolution records
- Records of training or orientation provided on the new process assets
Appraisal Considerations:
- The deployment plan typically includes such items as assets to be deployed,
schedules, resources, scope of the deployment, training, support tools, etc.
Artifact Examples:
- Plans for deploying organizational process assets and changes to them across
the organization
- Training materials for deploying organizational process assets and changes to
them
- Documentation of changes to organizational process assets
- Support materials for deploying organizational process assets and changes to
them
- Training materials for deploying the process assets and changes to process
assets
- Support materials for deploying the process assets and changes to process
assets
- Process asset library (PAL)
- Records of effort and expenditure associated with deployment
- Deployment issue identification and resolution records
- Records of training or orientation provided on the new process assets
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPF, Page 4
Page 27
Organizational Process Focus
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
5.1: Leadership and commitment: 5.1.1:
General: c) ensuring the integration of the
quality management system requirements into
the organization's business processes; g)
ensuring that the quality management system
achieves its intended results;
6.2: Quality objectives and planning to achieve
them: 6.2.2: e) how the results will be evaluated;
8.1: Operational planning and control: e)
determining, maintaining and retaining
documented information to the extent
necessary: 1) to have confidence that the
processes have been carried out as planned;
10.1: General
SP3.4Incorporate process-related experiences derived from planning
and performing the process into organizational process assets.
4.4: Quality management system and its
processes: 4.4.1
The Sprint Retrospective meeting may generate
action items to improve for the next sprint.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
5.1: Leadership and commitment: 5.1.1:
General: i) promoting improvement;
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
6.1: Actions to address risks and opportunities:
6.1.2: a) actions to address these risks and
opportunities; b) how to : 2) evaluate the
effectiveness of these actions;
6.2: Quality objectives and planning to achieve
them: 6.2.1: g) be updated as appropriate;
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
b) information derived from previous similar
design and development activities;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation
10.1: General
10.2: Nonconformity and corrective action:
10.2.1: f) make changes to the quality
management system, if necessary.
10.3: Continual improvement
Appraisal Considerations:
- The deployment plan typically includes such items as assets to be deployed,
schedules, resources, scope of the deployment, training, support tools, etc.
Artifact Examples:
- Plans for deploying the process assets and changes to process assets
- Documentation of changes to the process assets
- Generated process assets, methods, and tools
- Training materials for deploying the process assets and changes to process
assets
- Support materials for deploying the process assets and changes to process
assets
- Process asset library (PAL)
- Records of effort and expenditure associated with deployment
- Deployment issue identification and resolution records
- Records of training or orientation provided on the new process assets
Appraisal Considerations:
- Lessons learned could originate from deployment or use of the organization’s
process assets.
- Refer to the OPD PA for information regarding an organizational measurement
repository, including common measures.
Artifact Examples:
- Process lessons learned
- Measurements on the organization process assets
- Records of the organization's process improvement activities
- Revisions to organization’s process assets
- Process improvement proposals
- Improvement recommendations for the organization's process assets
- Information on the organization's process assets and improvements to them
- Analysis of process performance measures and process assets
- Reviews including process evaluations, process proposals, tracking of
improvement efforts, etc.
- Lessons learned repository
- Collection of best practices
- Process compliance checklists and audits
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPF, Page 5
Page 28
Organizational Performance Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1
The organization's business performance is managed
using statistical and other quantitative techniques to
understand process performance shortfalls, and to
identify areas for process improvement.
SP1.1Maintain business objectives based on an understanding of
business strategies and actual performance results.
4.1: Understanding the organization and its
context
“Strategic Theme success criteria provide
learning milestones that allow the portfolio to
understand the solutions involved, validated
business and technical hypotheses and where
necessary, pivot towards a better solution.”
5.1: Leadership and commitment: 5.1.2:
Customer focus: c) the focus on enhancing
customer satisfaction is maintained.
5.2: Policy: 5.2.1: Establishing the quality policy:
a) is appropriate to the purpose and context of
the organization and supports its strategic
direction; b) provides a framework for setting
quality objectives;
6.2: Quality objectives and planning to achieve
them: 6.2.1: b) be measurable;
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.3: Continual improvement
SP1.2Analyze process performance data to determine the organization's
ability to meet identified business objectives.
4.1: Understanding the organization and its
context
Lean Portfolio Metrics, determined by the
organization to best measure its ability to meet
its business objectives, are used to assess the
internal and external progress for the Portfolio
level, such as productivity, time to market,
quality, and employee engagement.
5.3: Organizational roles, responsibilities, and
authorities: c) reporting on the performance of
the quality management system and on
opportunities for improvement, in particular to
top management;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.3: Continual improvement
SP1.3Identify potential areas for improvement that could contribute to
meeting business objectives.
Appraisal Considerations:
- None
Artifact Example:
- Revised business objectives
- Revised quality and process performance objectives
- Senior management approval of revised business objectives and quality and
process performance objectives
- Communication of all revised objectives
- Updated process-performance measures
Appraisal Considerations:
- None
Artifact Example:
- Analysis of current capability vs. business objectives
- Process performance shortfalls
- Risks associated with meeting business needs and objectives
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPM, Page 1
Page 29
Organizational Performance Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
4.1: Understanding the organization and its
context
“The Program Portfolio Management (PPM)
team continuously assesses and improves their
processes. Often this is done using a structured,
periodic Self-Assessment . . . which highlights
relative strengths and weaknesses.” Self-
assessments are also used at the Team and
Program levels.
4.4.1: Quality management system and its
processes: f) address the risks and
opportunities as determined in accordance with
the requirements of 6.1; g)evaluate these
processes and implement any changes needed
to ensure that these processes achieve their
intended results; h) improve the processes and
the quality management system.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
5.2: Policy: 5.2.1: Establishing the quality policy:
d) includes a commitment to continual
improvement of the quality management
system.
5.3: Organizational roles, responsibilities, and
authorities: c) reporting on the performance of
the quality management system and on
opportunities for improvement, in particular to
top management;
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.3: Continual improvement
SG2
Improvements are proactively identified, evaluated using
statistical and other quantitative techniques, and
selected for deployment based on their contribution to
meeting quality and process performance objectives.
SP2.1 Elicit and categorize suggested improvements.
4.4.1: Quality management system and its
processes: h) improve the processes and the
quality management system.
The Iteration Retrospective evaluates what went
well and what did not go well in the last sprint,
and what they can change to improve the next
Iteration.
Appraisal Considerations:
- None
Artifact Example:
- Potential areas for improvement
Appraisal Considerations:
- Improvements to the organization’s process are typically identified through
feedback from users, by analyzing metrics data, based on corporate initiatives,
customer satisfaction surveys etc. The improvement proposals should be
analyzed based on criteria such as reduction cycle time, effort reduction etc.
Artifact Example:
- Suggested incremental improvements
- Suggested innovative improvements
- Organization’s quality and process performance objectives
- Process or technology improvements that were successfully adopted in some
projects
- Cost-Benefit Analysis data of improvement proposals
- Process Group Leadership Team Meeting Minutes showing ranking
- Quality Management System improvement form
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPM, Page 2
Page 30
Organizational Performance Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
10.3: Continual improvement
SP2.2
Analyze suggested improvements for their possible impact on
achieving the organization's quality and process performance
objectives.
4.4.1: Quality management system and its
processes: h) improve the processes and the
quality management system.
The Iteration Retrospective evaluates what went
well and what did not go well in the last Iteration,
and what they can change to improve the next
Iteration.
6.3: Planning of changes: a) the purpose of the
changes and their potential consequences;
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.3: Continual improvement
SP2.3 Validate selected improvements.
4.4: Quality management system and its
processes: 4.4.1: h) improve the processes and
the quality management system.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
10.3: Continual improvement
SP2.4
Select and implement improvements for deployment throughout
the organization based on an evaluation of costs, benefits, and
other factors.
4.4: Quality management system and its
processes: 4.4.1: h) improve the processes and
the quality management system.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
Appraisal Considerations:
- Improvements to the organization’s process are typically identified through
feedback from users, by analyzing metrics data, based on corporate initiatives,
customer satisfaction surveys etc. The improvement proposals should be
analyzed based on criteria such as reduction cycle time, effort reduction etc.
Artifact Example:
- Suggested incremental improvements
- Suggested innovative improvements
- Organization’s quality and process performance objectives
- Process or technology improvements that were successfully adopted in some
projects
- Cost-Benefit Analysis data of improvement proposals
- Process Group Leadership Team Meeting Minutes showing ranking
- Quality Management System improvement form
Appraisal Considerations:
- Innovative improvements can be items such as new tools/ techniques /
processed identified and used in projects. These Improvements to the
organization’s process are typically identified through feedback from users, by
analyzing metrics data, based on corporate initiatives, ICSM surveys etc. The
improvement proposals are analyzed based on criteria such as reduction cycle
time, effort reduction etc.
Artifact Example:
- Suggested improvement proposals
- Selected improvements to be validated
Appraisal Considerations:
- Piloting should be conducted on process automation tools and processes, as
required. The piloting feedback should be evaluated. The evaluation criteria
should be primarily focused on the requirements / functionality, performance and
other related parameters.
Artifact Example:
- Validation plans
- Validation evaluation reports
- Documented lessons learned from validation
Appraisal Considerations:
- The evaluated and selected process and technology improvements should be
deployed across the organization. The innovations should be institutionalized and
released through the organization's Quality Management System.
Artifact Example:
- Improvements selected for deployment
- Updated process documentation and trainingLast updated 8/20/17
This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPM, Page 3
Page 31
Organizational Performance Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
6.3: Planning of changes.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.2: Nonconformity and corrective action:
10.2.2: b) the results of any corrective action.
10.3: Continual improvement
SG3
Measurable improvements to the organization's
processes and technologies are deployed and evaluated
using statistical and other quantitative techniques.
SP3.1Establish and maintain plans for deploying selected
improvements.
4.4: Quality management system and its
processes: 4.4.1: h) improve the processes and
the quality management system.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.3: Continual improvement
SP3.2 Manage the deployment of selected improvements.
4.4: Quality management system and its
processes: 4.4.1: h) improve the processes and
the quality management system.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
Appraisal Considerations:
- The evaluated and selected process and technology improvements should be
deployed across the organization. The innovations should be institutionalized and
released through the organization's Quality Management System.
Artifact Example:
- Improvements selected for deployment
- Updated process documentation and training
Appraisal Considerations:
- For process automation tools, deployment plans should be prepared. This is
typically accomplished in a phased manner, probably a location or project at a
time. Training should be conducted to train people on the new tool. The
Organization Process Group or process improvement group typically facilitates
this deployment. The process deployment is often released through the
organization's Quality Management System and then through training to the
appropriate individuals. Sometimes release notes are used as well to highlight the
details of the process. This can be followed by a training to the quality assurance
team if the changes are major and significant. Project level innovations are
typically institutionalized by incorporating them into the organization's Quality
Management System.
Artifact Example:
- Deployment plans for selected improvements
- Deployment planning meeting minutes
Appraisal Considerations:
- The innovations and the improvements should be institutionalized through
release in the organization's Quality Management System
Artifact Example:
- Updated training materials (to reflect deployed improvements.
- Documented results of improvement deployment activities.
- Revised improvement measures, objectives, priorities, and deployment plans.
- Deployment status review meeting minutes
- Training Material on Process Improvements
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPM, Page 4
Page 32
Organizational Performance Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
10.3: Continual improvement
SP3.3
Evaluate the effects of deployed improvements on quality and
process performance using statistical and other quantitative
techniques.
4.4.1: Quality management system and its
processes: h) improve the processes and the
quality management system.
Iteration Retrospective meeting minutes or
action items may be an output from the meeting.
10.1: General: a) improving products and
services to meet requirements as well as to
address future needs and expectations;
The organization must determine and agree
upon which Metrics to use to measure their
quality and process performance, such as
program velocity, number of stories planned and
number of stories accepted, the number of
defects, and the unit test coverage percentage.
10.2: Nonconformity and corrective action:
10.2.1: d) review the effectiveness of any
corrective action taken;
10.3: Continual improvement
Appraisal Considerations:
- The innovations and the improvements should be institutionalized through
release in the organization's Quality Management System
Artifact Example:
- Updated training materials (to reflect deployed improvements.
- Documented results of improvement deployment activities.
- Revised improvement measures, objectives, priorities, and deployment plans.
- Deployment status review meeting minutes
- Training Material on Process Improvements
Appraisal Considerations:
- The feedback from the deployed process and innovations should be captured
and analyzed to understand the effects of the deployment.
Artifact Example:
- Documented measures of the effects resulting from the deployed improvements.
- OPM process status sheet including improved common causes of process
variation that meet organization’s quality and process performance objectives
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPM, Page 5
Page 33
Organizational Process Performance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1
Baselines and models, which characterize the expected
process performance of the organization's set of
standard processes, are established and maintained.
SP1.1
Establish and maintain the organization’s quantitative objectives
for quality and process performance, which are traceable to
business objectives.
4.1: Understanding the organization and its
context
The organization and scrum team must
determine their quantitative quality and process
performance objectives and maintain those
objectives based on past performance data.
The organization must determine their
quantitative quality and process performance
objectives and agree upon which Lean Portfolio
Metrics to use to measure their quality and
process performance.
5.1: Leadership and commitment: 5.1.1:
General: b) ensuring the integration of the
quality management system requirements into
the organization's business processes;
Agile is more measurable than waterfall-based
lifecycles. The best measure is working
software, which is delivered at the end of each
sprint.
SAFe® is more measurable than waterfall-
based lifecycles. The best measure is working
software and solutions.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed; c)
the focus on enhancing customer satisfaction is
maintained.
Strategic Themes can use success criteria to
measure progress towards the organization’s
business objectives.
5.2: Policy: 5.2.1: Establishing the quality policy
6.2: Quality objectives and planning to achieve
them: 6.2.1: b) be measurable;
6.2: Quality objectives and planning to achieve
them: 6.2.2: a) what will be done;
SP1.2
Select processes or subprocesses in the organization's set of
standard processes to be included in the organization's process
performance analyses and maintain traceability to business
objectives.
6.2: Quality objectives and planning to achieve
them: 6.2.2: a) what will be done;
During the PI (Program Increment) Inspect &
Adapt workshop, the teams review the
quantitative Metrics they have agreed to collect
to create their Program Performance Metrics,
and use the Program Predictability Measure to
determine the actual business value achieved
against the planned business value for each
team’s PI Objectives.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: a) what needs to be
monitored and measured;
The Value Stream Performance Metrics and the
Value Stream Predictability Measure are
created by aggregating the Program
Performance Metrics and the Program
Predictability Measures of each ART in the
Value Stream.
The Portfolio Performance Metrics are created
by aggregating the Value Stream Performance
Metrics of each Value Stream in the Portfolio.
Appraisal Considerations:
- The organization goals should be established that represent the quantitative
objectives for the organization
Artifact Example:
- Organization’s quality and process performance objectives
- Evidence that the project is managed quantitatively
- A developed & maintained Organizational Quality Management Plan
- Organization’s business objectives corresponding to quality and process
performance objectives
Appraisal Considerations:
- Metrics should be analyzed periodically to evaluate the process performance.
Based on internal audit reports, feedback etc. the process effectiveness should be
analyzed
Artifact Example:
- List of processes or subprocesses identified for process-performance analyses
- Organizational Quality Management Plan
- Organization’s and project’s needs or objectives
- Procedures on Organization metrics, Process analysis and/or Internal Quality
Audits
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPP, Page 1
Page 34
Organizational Process Performance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SP1.3Establish and maintain definitions of the measures to be included
in the organization's process performance analyses.
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability: a) calibrated or verified, or both, at
specified intervals, or prior to use, against
measurement standards traceable to
international or national measurement
standards; when no such standards exist, the
basis used for calibration or verification shall be
retained as documented information;
The organization must determine and agree
upon which Metrics to use to measure their
quality and process performance, such as
program velocity, number of stories planned and
number of stories accepted, the number of
defects, and the unit test coverage percentage.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: b) the methods for
monitoring, measurement, analysis and
evaluation needed to ensure valid results;
SP1.4Analyze the performance of the selected processes, and establish
and maintain the process performance baselines.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: d) when the results
from monitoring and measurement shall be
analysed and evaluated.
The organization must determine and agree
upon the process performance baselines to use
with the metrics they have chosen to measure
achievement of their quality and process
performance objectives.
Program Performance Metrics are collected at
the end of each Program Increment (PI).
An ART operating within 100% and 80% of their
achievement of business objectives per
Program Increment (PI) as measured by the
Program Predictability Measure is ideal in
SAFe® to allow the organization and outside
stakeholders to plan effectively.
SP1.5Establish and maintain process performance models for the
organization's set of standard processes.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General
The organization must evaluate the value of the
metrics they have chosen and the subprocesses
used such as the Program Predictability
Measure, and assess the effectiveness of those
metrics and subprocesses in showing how well
the organization is meeting its quality and
process performance objectives.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
Appraisal Considerations:
- Organizations baselines should be maintained in the organization’s process
database. A baseline analysis report should be prepared periodically.
Artifact Example:
- Baseline data on the organization’s process performance (e.g., sub-process
norms reports, productivity trend graphs, historical productivity data)
- Organizational Process Performance documentation and/or procedure(s)
- Raw metrics data from organizational measurement repository
- Meeting minutes regarding process capability and/or performance
Appraisal Considerations:
- None
Artifact Example:
- Organizational process performance documentation and/or procedure(s)
- Process capability analysis meeting minutes
- Resulting analysis based on use of process-performance models
- Process capability analysis meeting minutes
- Performance Baseline Metrics in Quality Program reports
- Organizational Inspection Baseline Data
Appraisal Considerations:
- The metrics and computation mechanisms should be defined and maintained.
The input data for the process performance analysis should be derived from
various sources and trend analysis should be generated.
Artifact Example:
- Definitions of selected measures of process performance
- Organizational Quality Management Plan
- Procedures on Organization metrics, Process analysis and/or Internal Quality
Audits
- Established Process Performance and Baseline Models
- Meeting minutes from process performance reviews
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPP, Page 2
Page 35
Organizational Training
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1A training capability, which supports the roles in the
organization, is established and maintained.
SP1.1 Establish and maintain strategic training needs of the organization.
7.2: Competence: a) determine the necessary
competence of person(s) doing work under its
control that affects the performance and
effectiveness of the quality management
system;
The organization and scrum team must
determine their strategic training needs and
objectives and implement a process for
maintaining strategic training needs based on
Agile practices.
"Strategic themes in SAFe® support the
economic framework and the Vision on the
Spanning palette. The Strategic themes are
supported by the Communities of Practice that
have been formed to help individuals and teams
advance their functional and cross-functional
skill for engaging in relentless improvement."
Pillar 4 in the “Lean-Agile Mindset”
“Create an environment that promotes
continuous learning, and foster formal and
informal groups for learning and improvement.
Encourage team members to build relationships
with customers and suppliers and expose them
to other world views. Strive to learn and
understand new developments in Lean, Agile,
and contemporary management practices.”
- #2 - “Know the way, emphasize lifelong
learning” - Leading the Lean-Agile Enterprise
In order to implement SAFe®, organizations
should follow SAFe®’s Implementing 1-2-3:
“first, train implementers and Lean-Agile change
agents (SAFe® Program Consultants AKA
SPCs)”, who then “train all executives,
managers, and leaders”, and finally the SPCs
“train teams and launch Agile Release Trains"
(ARTs).
SP1.2
Determine which training needs are the responsibility of the
organization and which are left to the individual work group or
support group.
Appraisal Considerations:
- None
Artifact Example:
- Training needs
- Review and revision history of the strategic training needs of the organization
- Assessment analysis
- Organization’s strategic business plan or process improvement plan
- Identification of roles and skills needed
- List of required training courses needed
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OT, Page 1
Page 36
Organizational Training
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Appraisal Considerations:
- It may be difficult to find explicit artifacts that identify organizational decisions on
training that is deferred to projects; i.e., evidence may exist on what training they
are going to provide, but not necessarily on what they decided not to train at the
organizational level. This might have to be obtained from interviews, or
substantiated by written organizational training process descriptions.
- There may be constraints or tradeoffs that practically limit the training needs that
can be immediately satisfied. Some training may reasonably need to be deferred
based on the extent of needs, resources, and priorities, but this tradeoff should be
part of the defined process.
- Consider training on tools, methods, and processes.
- Refer to Project Planning PA for more information about project and support
group plans for training.
Artifact Example:
- Training commitments
- A list of the training to be provided by the organization
- Common project and support group training needs
- Documented lists of special training needs required by projects or support groups
- Rationale for acceptance or rejection of training proposals
8.3:Design and development of products and
services: 8.3.2: Design and development
planning: c) the required design and
development verification and validation
activities; d) the responsibilities and authorities
involved in the design and development
process;
The organization and scrum team must
determine which training needs are the
organization’s responsibility and which are the
scrum team’s responsibility.
The organization must determine which training
needs are the responsibility of the organization
and which are the responsibility of the individual
group (Team, ART, or other SAFe® roles).
SP1.3 Establish and maintain an organizational training tactical plan.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: e)
the appointment of competent persons,
including any required qualifications;
The organization and scrum team must
determine their tactical training needs and
objectives and implement a process for
maintaining tactical training needs based on
Agile practices.
The organization at all levels of SAFe® must
determine their tactical training needs and
objectives and implement a process for
maintaining tactical training needs based on
SAFe® practices such as using the Innovation
and Planning (IP) Iteration.
The Scrum Master may be responsible for
determining training needs of the scrum team.
The Scrum Master (at the Team Level) and the
Release Train Engineer (at the Program Level)
may be responsible for determining training
needs of the scrum team.
SP1.4Establish and maintain a training capability to address
organizational training needs.Appraisal Considerations:
- See model for training approaches and materials; consider both formal and
informal methods for skills development.
Artifact Example:
- Training materials and supporting artifacts
- Analysis and revisions of training materials and resources
- Organization’s training curriculum and course descriptions
- Analysis of whether to acquire training or provide in-house
- Criteria for instructor qualifications
- Periodic reviews of training capability and resources
7.2: Competence: b) ensure that these persons
are competent on the basis of appropriate
education, training, or experience;
The organization and scrum team should
develop approaches and allot resources to
address organizational training needs.
The organization should develop approaches
and allot resources to address organizational
training needs.
SG2Training for individuals to perform their roles effectively
is provided.
SP2.1Deliver the training following the organizational training tactical
plan.
7.2: Competence: c) where applicable, take
actions to acquire the necessary competence,
and evaluate the effectiveness of the actions
taken;
Training employees in Agile practices and
processes may be implemented with the help of
an Agile Coach/Mentor, who may be an
employee or an outside consultant.
Training employees in SAFe® practices and
processes may be implemented with the help of
a SAFe® Program Consultant (SPC), who may
be an employee or an outside consultant.
Appraisal Considerations:
- See SP 1.3 subpractices for typical content and commitment of Organizational
Training Tactical Plans
Artifact Example:
- Organizational training tactical plan
- Adjustments or revision history of the organizational training tactical plan
- Lists of training courses, prerequisites, skills, schedules, funding, roles, and
responsibilities
- Reviews or status reports tracking implementation progress (e.g., schedule and
remaining budget) of the organizational training tactical plan.
Appraisal Considerations:
- Check criteria for training waivers
- Look for timeliness of delivered training
- Training should be delivered in accordance with the plan developed in SP 1.3
Artifact Example:
- Delivered training course
-Training records (schedule, instructor, attendance)
- Training delivery reports or metrics (e.g., planned vs. actual)
- Organization’s training plan
- Training curriculum, based on assigned role
- Prioritized list of pending training attendeesLast updated 8/20/17
This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OT, Page 2
Page 37
Organizational Training
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
In order to implement SAFe®, organizations
should follow SAFe®’s Implementing 1-2-3:
“first, train implementers and Lean-Agile change
agents (SAFe® Program Consultants AKA
SPCs)”, who then “train all executives,
managers, and leaders”, and finally the SPCs
“train teams and launch Agile Release Trains
(ARTs).
SP2.2 Establish and maintain records of organizational training.
7.2: Competence: d) retain appropriate
documented information as evidence of
competence.
Agile certifications such as the Certified Scrum
Master certification may be obtained and
tracked to ensure certification renewal.
SAFe® certifications such as the SPC (SAFe®
Program Consultant), SSM (SAFe® Scrum
Master), Scaled Agilist (SA), SAFe®
Practitioner (SP), and other certifications may
be obtained and tracked to ensure certification
renewal.
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: c) competence, including any
required qualification of persons;
SP2.3 Assess the effectiveness of the organization's training program.
7.2: Competence: c) where applicable, take
actions to acquire the necessary competence,
and evaluate the effectiveness of the actions
taken;
The Sprint Retrospective may evaluate the
effectiveness of training received by members of
the scrum team in relation to the sprint.
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: c) competence, including any
required qualification of persons;
The Iteration Retrospective may evaluate the
effectiveness of training received by the
members of an Agile team in relation to the
Iteration.
The Retrospective and Problem-Solving
Workshop may evaluate the effectiveness of the
Innovation and Planning (IP) Iteration’s training
and learning activities as well as the
effectiveness of any additional training.
Appraisal Considerations:
- This practice is geared towards organizational level training records. Project and
support group training records are in PMC. In practice, these may be combined at
the organizational level.
Artifact Example:
- Training records
- Attendance records and approved waivers
- Training updates to the organizational repository
- Skills matrix
- Training repository
- Training metrics or reports
- Training waiver procedures and criteria
Appraisal Considerations:
- This is organizational training, not project or support group level training.
Artifact Example:
- Training program performance assessments
- Reviews, analyses, or reports of organizational training effectiveness and
alignment with organization objectives
- Training effectiveness surveys
- Instructor evaluation forms
- Training examinations
- Student evaluation feedback forms (of how well training met their needs)
- Metrics or analysis summarizing consolidated training results
- Revised course materials, methods, or curriculum as a result of training feedback
Appraisal Considerations:
- Check criteria for training waivers
- Look for timeliness of delivered training
- Training should be delivered in accordance with the plan developed in SP 1.3
Artifact Example:
- Delivered training course
-Training records (schedule, instructor, attendance)
- Training delivery reports or metrics (e.g., planned vs. actual)
- Organization’s training plan
- Training curriculum, based on assigned role
- Prioritized list of pending training attendees
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OT, Page 3
Page 38
Project Monitoring and Control
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Actual progress and performance are monitored
against the work plan.
SP1.1Monitor actual values of planning parameters against the work
plan.
6.2: Quality objectives and planning to
achieve them: 6.2.1: e) be monitored;
The Sprint Burndown Chart shows the status
of the work that the development team has
completed and tracks actual progress to the
estimated schedule.
Agile project management tools are used to
track the status of stories, defects, test cases,
estimates, actuals, burndowns, and more.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: a) what needs to
be monitored and measured;
The Kanban board/story board shows the
status of stories and tasks being worked on
by the development team.
Metrics such as the Epic Progress Measure,
the Epic Burn-up Chart, the Feature Progress
Report, the PI Burn-down Chart, and the
Team PI Performance Report track estimated
progress against actual achieved progress.
SP1.2Monitor commitments against those identified in the work
plan.Appraisal Considerations:
- See Project Planning PA SP3.1 for review of subordinate plans to
understand work commitments
- See Project Planning PA SP3.3 for commitments obtained from relevant
stakeholders
- Consider commitments documented for relevant stakeholders, as in Project
Planning PA SP3.3
- Look at appraisal considerations for Project Planning PA SP3.3
- For some work plans there may be little (if any) formal evidence.
Affirmation may be the primary evidence of existence of this SP.
Artifact Example:
- Records of commitment reviews
- Project plans, and commitments tracking system
- Reviews of documented commitments and revisions as necessary (e.g.,
presentations)
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: d)
if planning has been implemented effectively;
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
SP1.3 Monitor risks against those identified in the work plan.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: e)
the effectiveness of actions taken to address
risks and opportunities;
The Product Owner and the development
team may create a list of acceptable risks to
go with their agreed-upon Definition of Done.
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
The PI Planning meeting identifies risks and
impediments that may affect the teams' ability
to meet the PI Objectives and categorizes
them using ROAM (resolved, owned,
accepted, mitigated) before each PI.
SP1.4 Monitor the management of data against the work plan.
Appraisal Considerations:
- See Project Monitoring and Control SP2.1, 2.2, 2.3 for corrective actions
taken
- See Measurement and Analysis PA for measuring, analyzing, and
recording the actual attributes of the work products and tasks and other
planning parameters and comparing them to their associated estimates
- See Project Planning PA for Project Planning parameters and plans to be
monitored
Artifact Example:
- Records of performance
- Records of significant deviations against plan
- Cost performance reports Example:
- Earned value management metrics
- Variance reports
- Status reports
- Relevant project management/milestone progress review materials
- Identified major milestones
- Project or organizational repository for performance measurements (also
see Project Monitoring and Control SP 1.4)
- Indications knowledge and skills of work personnel are monitored.
Appraisal Considerations:
- See Project Planning PA SP2.2 for more information about identifying
Project risks
- Frequency of risk monitoring should be as defined in the project plan.
Artifact Example:
- Records of Project risk Monitoring
- Periodic review and revision of risk status (e.g., probability, priority,
severity)
- Communications of risk status to relevant stakeholders.
· Defined criteria (e.g., procedure) used to monitor risks against those
identified in the Project plan
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PMC, Page 1
Page 39
Project Monitoring and Control
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.1: Operational planning and control: e)
determining, maintaining, and retaining
documented information to the extent
necessary:
Sprint Burndown Charts can show whether
the team is routinely updating their progress
or if they are failing to update or even lying
about their actual rate of progress.
Agile project management tools are used to
track the status of stories, defects, test cases,
estimates, actuals, burndowns, and more.
The ScrumXP practice of Continuous
Integration/Continuous Build imply the use of
a code repository for configuration
management.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build
imply the use of a code repository for
configuration management.
The Product Owner is responsible for creating
and maintaining the Product Backlog by
adding and prioritizing User Stories.
The Product Owner is responsible for creating
and maintaining the Team Backlog by adding
and prioritizing Stories.
SP1.5 Monitor stakeholder involvement against the plan.
8.7: Control of nonconforming outputs: 8.7.1:
c) informing the customer;
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
The Sprint Review meeting solicits comments
and feedback from stakeholders on the
product created during the sprint.
The Team Demo and System Demo meeting
solicits comments and feedback from
stakeholders on the product created during
the Iteration/Program Increment.
SP1.6Periodically review the work progress, performance, and
issues.
6.2: Quality objectives and planning to
achieve them: 6.2.1: e) be monitored;
The Sprint Burndown Chart shows the status
of the work that the development team has
completed and tracks actual progress to the
estimated schedule.
Agile project management tools are used to
track the status of stories, defects, test cases,
estimates, actuals, burndowns, and more.
8.2: Requirements for products and services:
8.2.1: Customer communication: b) handling
enquiries, contracts or orders, including
changes;
The Task Board shows which user stories
and tasks are ready to do, are in progress,
are ready to be accepted, and are done.
The Kanban board/story board shows the
status of stories and tasks being worked on
by the development team.
8.6: Release of products and services: a)
evidence of conformity with the acceptance
criteria;
The Daily Stand-up Meeting addresses
completed tasks, tasks that will be done, and
any impediments.
The Daily Stand-up Meeting addresses
completed tasks, tasks that will be done, and
any impediments.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: c) when the
monitoring and measuring shall be
performed;
The Product Owner Review verifies that
completed user stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: d)
if planning has been implemented effectively;
SP1.7 Review accomplishments and results at selected milestones.
6.2: Quality objectives and planning to
achieve them: 6.2.1: g) be updated as
appropriate;
The Sprint Review meeting demonstrates and
reviews the completed user stories at the end
of the sprint.
The Team Demo and System Demo
demonstrates the completed work at the end
of the Iteration/Program Increment.
Appraisal Considerations:
- See Project Planning PA SP2.3 for planning for identifying the types of data
that should be managed and how to plan for their management
- See Project Monitoring and Control SP1.1 for measurement repository
Artifact Example:
- Records of data management
- Data management reports (e.g., inventory, delivery schedules and status)
- Reviews/inventories/master lists or audits of project data repository status
- Results of data management reviews
- Master list of managed data
- Data management plan
Appraisal Considerations:
- See Project Planning PA SP2.6 for planning the involvement with identified
stakeholders
Artifact Example:
- Records of stakeholder involvement
- Stakeholder meeting and communications schedules
- Distribution lists for communication of issues
- Stakeholder correspondence with issues indicated
- Mechanisms/tools for monitoring and resolving stakeholder issues (e.g.,
files and spreadsheets)
Appraisal Considerations:
- Ref. Project Monitoring and Control SP 2.1 for collecting and analyzing the
issues and determining the corrective actions necessary to address the
issues
- Work progress reviews may be informal, and not specified explicitly in work
plans.
Artifact Example:
- Documented work review results
- Collection and analyses of work performance measures (schedules, effort,
deviations from plan)
- Records of communications of work status to relevant stakeholders
- Records of issues, change requests, problem reports for work products and
processes
- Defined criteria (e.g., procedure) used for periodically reviewing the work’s
progress, performance, and issues (including work products, services
delivered, processes, schedules/intervals, and checklists/standards for
conducting reviews).
Appraisal Considerations:
- Refer to the Project Planning PA (SP 2.1) for more information about
milestone planning
- Milestone reviews are specified in the work plan and schedule, and can be
event based or calendar based.
Artifact Example:
- Documented milestone review results
- Milestone progress performance indicators
- Defined criteria (e.g., procedure) used to review the accomplishments and
results of the work at selected milestones (including definitions of milestones
- Standards/formats/checklists supporting milestone reviews
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PMC, Page 2
Page 40
Project Monitoring and Control
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.5: Production and service provision: 8.5.1:
Control of production and service provision: c)
the implementation of monitoring and
measurement activities at appropriate stages
to verify that criteria for control of processes
or outputs, and acceptance criteria for
products and services, have been met; f) the
validation, and periodic revalidation, of the
ability to achieve planned results of the
processes for production and service
provision, where the resulting output cannot
be verified by subsequent monitoring or
measurement;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: c) when the
monitoring and measuring shall be
performed; d) when the results from
monitoring and measurement shall be
analysed and evaluated.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: d)
if planning has been implemented effectively;
SG2
Corrective actions are managed to closure when the
work performance or results deviate significantly
from the plan.
SP2.1Collect and analyze issues and determine corrective actions to
address them.
8.1: Operational planning and control: The
organization shall control planned changes
and review the consequences of unintended
changes, taking action to mitigate any
adverse effects, as necessary.
The Sprint Retrospective meeting reviews
how the sprint went and what could be
changed to improve the next sprint.
The Iteration Retrospective evaluates what
went well and what did not go well in the last
Iteration, and what they can change to
improve the next Iteration.
8.7: Control of nonconforming outputs: 8.7.1:
b) segregation, containment, return or
suspension of provision of products and
services;
8.7: Control of nonconforming outputs: 8.7.2:
a) describes the nonconformity; b) describes
the actions taken; c) describes any
concessions obtained; d) identifies the
authority deciding the action in respect of the
nonconformity.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.2: Customer satisfaction
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: e)
the effectiveness of actions taken to address
risks and opportunities;
10.1: General
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 1) take action to control and
correct it;
Appraisal Considerations:
- See Project Monitoring and Control SP1.1 for monitoring of project actual
parameters and identifying deviations from the work plan
- See Project Monitoring and Control SP1.6 for review of issues
- Ref. Project Planning PA SP2.1, subpractice 6 for information about
corrective action criteria.
Artifact Example:
- List of issues needing corrective actions
- See Model for examples of issues that may be gathered.
Appraisal Considerations:
- Refer to the Project Planning PA (SP 2.1) for more information about
milestone planning
- Milestone reviews are specified in the work plan and schedule, and can be
event based or calendar based.
Artifact Example:
- Documented milestone review results
- Milestone progress performance indicators
- Defined criteria (e.g., procedure) used to review the accomplishments and
results of the work at selected milestones (including definitions of milestones
- Standards/formats/checklists supporting milestone reviews
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PMC, Page 3
Page 41
Project Monitoring and Control
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
10.2: Nonconformity and corrective action:
10.2.2: a) the nature of the nonconformities
and any subsequent actions taken;
SP2.2 Take corrective action on identified issues.
8.1: Operational planning and control: The
organization shall control planned changes
and review the consequences of unintended
changes, taking action to mitigate any
adverse effects, as necessary.
Sprint Retrospective meeting minutes or
action items may be an output from the
meeting.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
8.2: Requirements for products and services:
8.2.1: Customer satisfaction: c) obtaining
customer feedback relating to products and
services, including customer complaints;
The Retrospective and Problem-Solving
Workshop generates improvement stories
and features to be fed directly into the
following PI (Program Increment) Planning
session. During PI Planning, the RTE
(Release Train Engineer) helps ensure that
the relevant improvement Stories are loaded
onto the Iteration plans, thus ensuring that
action will be taken and resources allocated,
as with any other backlog item.
8.7: Control of nonconforming outputs: 8.7.1:
b) segregation, containment, return or
suspension of provision of products and
services;
8.7: Control of nonconforming outputs: 8.7.2:
c) describes any concessions obtained;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.2: Customer satisfaction
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: e)
the effectiveness of actions taken to address
risks and opportunities;
10.1: General
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 1) take action to control and
correct it;
10.2: Nonconformity and corrective action:
10.2.2: a) the nature of the nonconformities
and any subsequent actions taken;
SP2.3 Manage corrective actions to closure.
8.1: Operational planning and control: The
organization shall control planned changes
and review the consequences of unintended
changes, taking action to mitigate any
adverse effects, as necessary.
The Sprint Retrospective meeting may
generate action items to improve for the next
sprint.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
Appraisal Considerations:
- Ref. Project Planning PA when work re-planning is needed. The corrective
actions may require re-planning, which may include revising the original
plan, establishing new agreements, or including mitigation activities within
the current plan.
Artifact Example:
- Corrective action plan
- · Defined criteria (e.g., procedure) used to develop the corrective action
plan and take corrective action on identified issues.
Appraisal Considerations:
- None
Artifact Example:
- Corrective action results
- Review and meeting minutes associated with corrective actions
- Corrective action effectiveness analysis
- Closed corrective action requests
Appraisal Considerations:
- See Project Monitoring and Control SP1.1 for monitoring of project actual
parameters and identifying deviations from the work plan
- See Project Monitoring and Control SP1.6 for review of issues
- Ref. Project Planning PA SP2.1, subpractice 6 for information about
corrective action criteria.
Artifact Example:
- List of issues needing corrective actions
- See Model for examples of issues that may be gathered.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PMC, Page 4
Page 42
Project Monitoring and Control
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.7: Control of nonconforming outputs: 8.7.1:
b) segregation, containment, return or
suspension of provision of products and
services;
The Retrospective and Problem-Solving
Workshop generates improvement stories
and features to be fed directly into the
following PI (Program Increment) Planning
session. During PI Planning, the RTE
(Release Train Engineer) helps ensure that
the relevant improvement Stories are loaded
onto the Iteration plans, thus ensuring that
action will be taken and resources allocated,
as with any other backlog item.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: e)
the effectiveness of actions taken to address
risks and opportunities;
10.1: General
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 1) take action to control and
correct it;
10.2: Nonconformity and corrective action:
10.2.1: d) review the effectiveness of any
corrective action taken;
10.2: Nonconformity and corrective action:
10.2.2: a) the nature of the nonconformities
and any subsequent actions taken;
Appraisal Considerations:
- None
Artifact Example:
- Corrective action results
- Review and meeting minutes associated with corrective actions
- Corrective action effectiveness analysis
- Closed corrective action requests
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PMC, Page 5
Page 43
Project Planning
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts and Ceremonies SAFe® 4.0 Practices and Principles
SG1Estimates of Project Planning parameters are established and
maintained.
SP1.1Establish a top-level work breakdown structure (WBS) to estimate
the scope of the project.Appraisal Considerations:
- Determination of WBS usage for this practice must be based on top-level WBS
only, not its fully elaborated and expanded form as referenced in subsequent
practices of this PA
- Top-level work breakdown structure should be driven by and linked to specified
product and service requirements. (See Requirements Management PA)
- See Supplier Agreement Management process area for more information about
acquiring work products and services from other sources external to the project
- Level of supporting documentary evidence will vary based on project
size/duration. Larger projects may have minutes from estimation meetings,
estimation teams, and tools use, etc. Smaller may have none. Appraisal team will
need consensus on the WBS elements that will be expected. See PP SP1.4-1 for
derivation of detailed work breakdown structures from top-level work breakdown
structures.
Artifact Example:
- Task Descriptions
- Work Breakdown Structure
- Top-level WBS revision history
- Task descriptions
- Work product descriptions
- Product requirements, product roadmaps
- Organizational standard WBS template
- Identification of work products (or components of work products) that will
externally acquired.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process states, including applicable
design and development activities;
Requirements may be broken down
(decomposed) into Themes, Features, Epic
User Stories, User Stories, or Tasks, which
describe the requirements in terms of its value
to the end user.
Functional system behavior is described and
broken down, from Epics to Capabilities,
Features, and then Stories at the Portfolio,
Value Stream, Program, and Team levels,
respectively.
SP1.2Establish and maintain estimates of the attributes of the work
products and tasks.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
a) functional and performance requirements; b)
information derived from previous similar design
and development activities; c) statutory and
regulatory requirements; d) standards or codes
of practices that the organization has committed
to implement;
Story Points estimate the value and effort for
each requirement.
Story Points estimate the value and effort for
each Story.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: a) the results to be achieved are
defined;
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
SP1.3 Define lifecycle phases on which to scope the planning effort.
Appraisal Considerations:
- Estimates should be consistent with project requirements to determine the
project’s effort, cost, and schedule.
Artifact Example:
- Number of requirements
- Number and complexity of interfaces
- Volume of data
- Number of risk items
- Number of service levels
- Availability of services, by service level (e.g., turnaround time, operational
availability ratio, number of calls the help desk should be able to handle per hour)
- Number of stakeholders affected by a service level
- Experience of work group participants
- Team velocity or productivity
- Geographic dispersal of work group members
- Proximity of customers, users, and suppliers
- Technical approach
- Size and complexity of tasks, services and work products
- Estimating models
- Estimating tools, algorithms, and procedures
- Operational definitions (e.g., procedure/criteria) for establishing and
documenting the estimates of the attributes of the work products, services and
tasks
- Bases of Estimates (BOEs)
- Use of validated models
- Use of models that are calibrated with historical data.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 1
Page 44
Project Planning
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts and Ceremonies SAFe® 4.0 Practices and Principles
Appraisal Considerations: - The project life cycle consists of phases that need
to be defined depending on the scope of requirements, the estimates for project
resources, and the structure of the project
- Larger projects may contain multiple phases
- Phases may contain subphases
- Depending on the strategy for development, there may be intermediate phases
e.g. prototyping, increments of capability.
Direct Artifact Example:
- Life-cycle phases
Indirect Artifact Example:
- Product life-cycle phases
- List of major milestones, events, or decision gates
- Risks and factors influencing life cycle selection (e.g., resources, schedules,
deliverables)
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process states, including applicable
design and development activities;
The Agile process (ScrumXP, Kanban) is the
lifecycle.
SAFe® provides the practices, processes, and
lifecycles for how the projects are done.
SP1.4Estimate effort and cost for work products and tasks based on
estimation rationale.
7.1: Resources: 7.1.1: General.
The Product Backlog Estimate is the total
number of story points in the Product Backlog
and is used to predict project length.
Story Points estimate the value and effort for
each requirement.
Story Points estimate the value and effort for
each Story.
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
Long-term estimates can be made using Epic-
level Story Point estimation, the velocity of each
ART, and an estimate of the capacity allocation
given to the project.
SG2A work plan is established and maintained as the basis
for managing the work.
SP2.1 Establish and maintain the budget and schedule.
8.2: Requirements for products and services:
8.2.1: Customer satisfaction: b) handling
enquiries, contracts or orders, including
changes;
Lean-Agile Budgeting funds Value Streams and
allocated by the Value Stream Engineer and
Portfolio Program Management for resources
and personnel based on the Roadmap and
current backlog needs.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; e) the
internal and external resource needs for the
design and development of products and
services;
The SAFe® Roadmap consists of the upcoming
planned and committed Program Increment
(PIs) and the next planned PIs, with upcoming
Milestones indicated.
The Release Plan schedules the release of a
specific set of features.
The PI Planning meeting generates the PI
Objectives for the next Program Increment (PI),
as well as a “program board” for each
dependency, Milestone, and Feature/Enabler
planned for each Iteration.
The Sprint Backlog shows all of the user stories
in a sprint and related tasks.
The Team Backlog contains all of the things that
the team needs to do to advance their part of
the work.
Appraisal Considerations:
- See PP SP1.1 for development of detailed work breakdown structure
- See PP SP1.2 for development of attributes of the work products, services and
tasks
Artifact Example:
- Effort estimates
- Cost estimates
- Documented assumptions, constraints, and rationale affecting project estimates,
and identify risks
- Bases of Estimates (BOEs)
- Estimation rationale
- Historical data or repository from previously executed projects
- Estimating methods (e.g., Delphi), models, tools, algorithms, and procedures
- Support needs (e.g., facilities and equipment resources)
Appraisal Considerations:
- This SP accumulates the work effort and cost estimates generated in PP SP1.4
- See subpractice 5 for typical activities in development of budget and schedule
- See WMC SP1.1 and SP2.2 for factors that may drive re-planning activities
Artifact Example:
- Schedules
- Schedule dependencies
- Budget
- Staffing profile· Identified major milestones
- Scheduling assumptions and constraints
- Task dependencies
- Criteria for corrective action based on deviation from project plan
- Comparisons of actual project performance results to estimates (for re-planning)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 2
Page 45
Project Planning
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts and Ceremonies SAFe® 4.0 Practices and Principles
The Sprint Burndown Chart shows the status of
the work that the development team has
completed.
The Team Burndown Chart or Team Kanban
shows the status of the development team's
work-in-progress (WIP).
SP2.2 Identify and analyze risks.
10.2: Nonconformity and corrective action:
10.2.1: e) update risks and opportunities
determined during planning, if necessary;
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
The PI Planning meeting identifies risks and
impediments that may affect the teams' ability to
meet the PI Objectives and categorizes them
using ROAM (resolved, owned, accepted,
mitigated) before each PI.
SP2.3 Plan for the management of data.
8.1: Operational planning and control: e)
determining, maintaining, and retaining
documented information to the extent
necessary:
The ScrumXP practice of Continuous
Integration/Continuous Build imply the use of a
code repository for configuration management.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build imply
the use of a code repository for configuration
management.
Information radiators capture information about
the project including the sprint burndown chart,
kanban boards, and any other information about
the project such as the Definition of Done.
During Iteration Execution, Teams use a Big
Visible Information Radiator (BVIR) such as
Kanban boards or story boards to track the
status of Stories, defects, and other activities
being worked on during the Iteration.
SP2.4 Plan for resources to perform the work.
8.1: Operational planning and control: c)
determining the resources needed to achieve
conformity to the product and service
requirements;
The ScrumXP practice of Coding Standards
requires the development and use of coding and
design standards by the scrum team for project
development.
Lean-Agile Budgeting funds Value Streams and
allocated by the Value Stream Engineer and
Portfolio Program Management for resources
and personnel based on the Roadmap and
current backlog needs.
Appraisal Considerations:
- The work plan typically contains a list of risks
- See Risk Management process area for more information about risk management
activities
- See WMC SP1.3 for more information about monitoring risks against those
identified in the work plan.
Artifact Example:
- Identified risks
- Risk impacts and probability of occurrence
- Risk priorities
- Records of stakeholder involvement in risk identification activities
- Criteria to be used to identify and analyze project risks.
Appraisal Considerations:
- See WMC SP1.4 for monitoring the management of project data
- See MA PA for planning for the definition, collection, and analysis of work
progress and performance data.
Artifact Example:
- Data management plan
- Master list of managed data
- Data content and format description
- Lists of data requirements for acquirers and suppliers
- Privacy requirements
- Security requirements
- Security procedures
- Mechanisms for data retrieval, reproduction, and distribution
- Schedule for the collection of project data
- List of project data to be collected
- Data content and format description
- Data requirements lists for acquirers and for suppliers
- Privacy requirements
- Security requirements
- Security procedures
- Mechanism for data retrieval, reproduction, and distribution
- Schedule for collection of project data
- Listing of project data to be collected
- Project data management repository and access mechanisms
- Project data identified, collected and distributed.
Appraisal Considerations:
- See PP SP1.1 for top-level work breakdown structure from which detailed WBS
work packages and WBS task dictionaries are derived
- See PP SP2.5 for the planning for knowledge and skills needed to perform the
work
- See Organizational Training process area for more information on knowledge
and skills information to be incorporated on the work plan.
Artifact Example:
- WBS work packages
- WBS task dictionary
- Staffing requirements based on work size and scope
- Staffing plans and profiles
- Critical facilities/equipment list
- Facilities plan
- Process/workflow definitions and diagrams
- Work administration requirements list
- Status reports
- Program administration requirements list
- Budget reviews
- Long lead-time items identified early.
Appraisal Considerations:
- This SP accumulates the work effort and cost estimates generated in PP SP1.4
- See subpractice 5 for typical activities in development of budget and schedule
- See WMC SP1.1 and SP2.2 for factors that may drive re-planning activities
Artifact Example:
- Schedules
- Schedule dependencies
- Budget
- Staffing profile· Identified major milestones
- Scheduling assumptions and constraints
- Task dependencies
- Criteria for corrective action based on deviation from project plan
- Comparisons of actual project performance results to estimates (for re-planning)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 3
Page 46
Project Planning
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts and Ceremonies SAFe® 4.0 Practices and Principles
During the Management Review and Problem-
Solving phase of PI Planning, management
agrees to planning adjustments based on
scope, resource, and dependency constraints.
SP2.5 Plan for knowledge and skills needed to perform the work.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: d) the responsibilities and authorities
involved in the design and development
process;
Training employees in Agile practices and
processes may be implemented with the help of
an Agile Coach/Mentor, who may be an
employee or an outside consultant.
Training employees in SAFe® practices and
processes may be implemented with the help of
a SAFe® Program Consultant (SPC), who may
be an employee or an outside consultant.
Lean-Agile Budgeting funds Value Streams and
allocated by the Value Stream Engineer and
Portfolio Program Management for resources
and personnel based on the Roadmap and
current backlog needs.
SP2.6 Plan the involvement of identified stakeholders.
8.2: Requirements for products and services:
8.2.1: Customer communication: a) providing
information relating to products and services;
The roles and responsibilities of the Product
Owner, Scrum Master, the development team,
the customer, and other stakeholders are
defined by Scrum.
The roles and responsibilities of each level of
SAFe® are defined by the Framework.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: d) the responsibilities and authorities
involved in the design and development
process;
Key stakeholders including the Product
Management, Agile Teams, System and
Solution Architect/Engineering, and the System
Team all attend and participate in the PI
Planning meeting.
SP2.7 Establish and maintain the overall project plan.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning
The Product Roadmap / Product Backlog
identifies and groups the product requirements
and prioritizes and creates high-level time
frames. It is updated throughout the project.
The SAFe® Roadmap consists of a the
upcoming planned and committed Program
Increment (PIs) and the next planned PIs, with
upcoming Milestones indicated.
The Program and Value Stream Backlog
contains all of the upcoming work that affects
the Solution, including Features/Capabilities and
Enablers.
The Release Plan schedules the release of a
specific set of features.
The PI Planning meeting generates the PI
Objectives for the next Program Increment (PI),
as well as a “program board” for each
dependency, Milestone, and Feature/Enabler
planned for each Iteration.
The Sprint Backlog shows all of the user stories
in a sprint and related tasks.
The Team Backlog contains all of the things that
the team needs to do to advance their part of
the work.
Appraisal Considerations:
- The needed knowledge and skills in this SP should be compared with those
provided by the work staff as determined in PP SP2.4
- See Organizational Training process area for more information on knowledge
and skills information to be incorporated on the work plan.
Artifact Example:
- Inventory of skill needs
- Staffing and new hire plans
- Databases (e.g. skills, training)
- Training plans
- Databases (e.g., skills and training)
Appraisal Considerations:
- See model for examples of typical contents of the stakeholder involvement plan
- This is an accumulation of the stakeholders across all PAs as a result of GP2.7
- See PMC SP 1.5 for monitoring stakeholder involvement against the project plan
- Stakeholder involvement will vary with project phase and activity and in any
project re-planning
Artifact Example:
- Stakeholder involvement plan
- List of relevant stakeholders for the project
- Schedule for stakeholder interaction
- Roles and responsibilities for stakeholders
- Defined criteria (e.g., procedure) used to plan the involvement with identified
stakeholders
Appraisal Considerations:
- Consider periodic revisions to the project plan due to changes in status of its
dependencies (See PP SP 3.2)
- The overall project plan ties together all the subordinate planning information;
this may be a single plan or consolidation of multiple plans
- The project plan resolves issues and conflicts associated with the subordinate
plans.
Artifact Example:
- Overall project plan
- Project plan revision history
- Issues and conflicts identified across subordinate plans
- IMP, IMS, SEMP, SDP (see model)
Appraisal Considerations:
- See PP SP1.1 for top-level work breakdown structure from which detailed WBS
work packages and WBS task dictionaries are derived
- See PP SP2.5 for the planning for knowledge and skills needed to perform the
work
- See Organizational Training process area for more information on knowledge
and skills information to be incorporated on the work plan.
Artifact Example:
- WBS work packages
- WBS task dictionary
- Staffing requirements based on work size and scope
- Staffing plans and profiles
- Critical facilities/equipment list
- Facilities plan
- Process/workflow definitions and diagrams
- Work administration requirements list
- Status reports
- Program administration requirements list
- Budget reviews
- Long lead-time items identified early.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 4
Page 47
Project Planning
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts and Ceremonies SAFe® 4.0 Practices and Principles
The Sprint Burndown Chart shows the status of
the work that the development team has
completed.
Agile project management tools are used to
track the status of stories, defects, test cases,
estimates, actuals, burndowns, and more.
SG3Commitments to the work plan are established and
maintained.
SP3.1Review all plans that affect the work to understand project
commitments.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning
The Product Vision Statement must be
understood by the project stakeholders,
development team, and the Scrum Master.
All team members must understand the Solution
Vision, and each level of SAFe® develops their
own Vision of how they will help meet higher-
level objectives.
The Product Roadmap / Product Backlog may
be created with input from stakeholders and the
development team.
User stories are created with input from
stakeholders and the development team.
User stories are created with input from
stakeholders and the development team.
Sprint Planning is performed together by the
Product Owner, Scrum Master, and the
development team.
Iteration Planning is performed together by the
Product Owner, Scrum Master, and the
development team.
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
The Daily Stand-up Meeting coordinates
development team members and establishes
the day’s priorities.
SP3.2Adjust the work plan to reconcile available and estimated
resources.
8.2: Requirements for products and services:
8.2.3.2: b) on any new requirements for the
products and services;
The Sprint Retrospective meeting reviews how
the sprint went and what could be changed to
improve the next sprint.
The Iteration Retrospective evaluates what went
well and what did not go well in the last Iteration,
and what they can change to improve the next
Iteration.
8.2: Requirements for products and services:
8.2.4: Changes to requirements for products and
services
The Product Roadmap / Product Backlog is a
living document to which requirements can be
added or changed.
The Roadmap is developed and updated by
Solution and Product Management as the Vision
and delivery strategy evolve.
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: a) design and development changes;
SP3.3Obtain commitment from relevant stakeholders responsible for
performing and supporting plan execution.
8.2: Requirements for products and services:
8.2.1: Customer communication: a) providing
information relating to products and services;
The Product Vision Statement must be
understood by the project stakeholders,
development team, and the Scrum Master.
All team members must understand the Solution
Vision, and each level of SAFe® develops their
own Vision of how they will help meet higher-
level objectives.
To create the Product Roadmap / Product
Backlog, the Product Owner works with the
stakeholders to determine the value of each
requirement, and the development team to
determine the level of effort to create each
requirement.
Appraisal Considerations:
- This practice considers the compatibility of other plans that may be related or
subordinate to the work plan. This may include plans called for in other CMMI
process areas, many of which are described by GP2.2 (Plan the Process). An
organization may choose to develop separate plans, or integrate all content into a
single work plan.
Artifact Example:
- Record of the reviews of plans that affect the work
- Work plan· Integrated work plans
- Evidence of work plan coordination meetings and correspondence
Appraisal Considerations:
- See model for examples of how reconciliation may be accomplished; note that
this does not necessarily imply revisions to the work plan
- Revised plans, etc., should be re-communicated to the affected parties.
Artifact Example: ·
- Revised methods and corresponding estimating parameters (e.g., better tools,
the use of off-the-shelf components)
- Renegotiated budgets
- Revised schedules
- Revised requirements list
- Renegotiated stakeholder agreements
- Revised methods and corresponding estimating parameters (e.g., better tools,
use of off-the-shelf components)
- Project change requests
- Project plan revision history
Appraisal Considerations:
- Commitments may include relevant stakeholders, both internal and external to
the project and organization. This should include the individuals responsible for
providing the resources identified in the plan (e.g., staffing, facilities, funding)
- Commitment is typically demonstrated by signature, but may include other
mechanisms
- For commitments external to the organization, this practice may be satisfied by
an implicit agreement, e.g., a clear communication of the needed resource,
signature of a contract referencing the plan or resource
- Commitment by those implementing the plan may be demonstrated by a
representative of the implementers, e.g., a leader signing for their staff
- Ensure this is performed not only for the initial project plan, but also for
subsequent reconciliation and changes (see PP SP3.2).
Artifact Example:
- Documented requests for commitments
- Documented commitments
- Documented requests for commitments
- Commitment review meeting minutes
- Identification and documentation of issues
- Identified commitments on interfaces between elements in the work, with other
work efforts, and organizational units.
Appraisal Considerations:
- Consider periodic revisions to the project plan due to changes in status of its
dependencies (See PP SP 3.2)
- The overall project plan ties together all the subordinate planning information;
this may be a single plan or consolidation of multiple plans
- The project plan resolves issues and conflicts associated with the subordinate
plans.
Artifact Example:
- Overall project plan
- Project plan revision history
- Issues and conflicts identified across subordinate plans
- IMP, IMS, SEMP, SDP (see model)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 5
Page 48
Project Planning
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts and Ceremonies SAFe® 4.0 Practices and Principles
The Release Plan requires the development
team’s consensus and commitment with the
Product Owner on the release date and the
release goal.
One of the outputs of PI Planning is a vote of
confidence/commitment from all of the Teams
on the Agile Release Train (ART)
Sprint Planning is performed together by the
Product Owner, Scrum Master, and the
development team.
Iteration Planning is performed together by the
Product Owner, Scrum Master, and the
development team, and Iteration Goals are
collaboratively developed.
User stories are created with input from
stakeholders and the development team.
User stories are created with input from
stakeholders and the development team.
Appraisal Considerations:
- Commitments may include relevant stakeholders, both internal and external to
the project and organization. This should include the individuals responsible for
providing the resources identified in the plan (e.g., staffing, facilities, funding)
- Commitment is typically demonstrated by signature, but may include other
mechanisms
- For commitments external to the organization, this practice may be satisfied by
an implicit agreement, e.g., a clear communication of the needed resource,
signature of a contract referencing the plan or resource
- Commitment by those implementing the plan may be demonstrated by a
representative of the implementers, e.g., a leader signing for their staff
- Ensure this is performed not only for the initial project plan, but also for
subsequent reconciliation and changes (see PP SP3.2).
Artifact Example:
- Documented requests for commitments
- Documented commitments
- Documented requests for commitments
- Commitment review meeting minutes
- Identification and documentation of issues
- Identified commitments on interfaces between elements in the work, with other
work efforts, and organizational units.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 6
Page 49
Process and Product Quality Assurance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1
Adherence of the performed process and associated
work products to applicable process descriptions,
standards, and procedures is objectively evaluated.
SP1.1Objectively evaluate selected performed processes against
applicable process descriptions, standards, and procedures.
4.1: Understanding the organization and its
context
The Sprint Retrospective meeting discusses
what processes went well and what did not in
the sprint, and what changes could be made to
improve the next sprint, involving the Product
Owner, Scrum Master, and development team.
The Iteration Retrospective evaluates what went
well and what did not go well in the last Iteration,
and what they can change to improve the next
Iteration.
4.3: Determining the scope of the quality
management system c) the products and
services of the organization.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
allocated, as with any other backlog item.
4.4: Quality management system and its
processes: 4.4.1
5.3: Organizational roles, responsibilities, and
authorities: a) ensuring that the quality
management system conforms to the
requirements of this International Standard; b)
ensuring that the processes are delivering their
intended outputs;
8.1: Operational planning and control: e)
determining, maintaining and retaining
documented information to the extent
necessary: 2) to demonstrate the conformity of
products and services to their requirements.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: e) any necessary actions are taken on
problems determined during the reviews, or
verification and validation activities;
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: b) the approval of: 2)
methods, processes and equipment;
8.6: Release of products and services
8.6: Release of products and services: a)
evidence of conformity with the acceptance
criteria;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.2: Customer satisfaction
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: b) the
degree of customer satisfaction;
Appraisal Considerations:
- “This process area primarily applies to evaluations of projects and services, but
also applies to evaluations of non-project activities and work products such as
training evaluations.”
- Refer to the Project Planning PA for more information about identifying processes
to be objectively evaluated
- Consider the PPQA PA as an enabler for GP2.9 in the context of other process
areas
- The frequency of evaluations or audits is typically defined in a quality assurance
plan. Look for evaluations performed throughout the lifecycle, not just at the end a
project or in close proximity to the assessment
- A typical implementation of this practice is through the development and use of a
quality assurance plan that may be a standalone document or incorporated into
another plan
- Depending on the culture of the organization, the process and product quality
assurance role may be performed, partially or completely, by peers, and the
quality assurance function may be embedded in the process.
Artifact Example:
- Audit reports
- Noncompliance reports
- Corrective actions
- Quality assurance plan, identifying the processes subject to evaluation, and
procedures for performing evaluations
- Applicable process descriptions, standards, and procedures
- Action items for noncompliance issues, tracked to closure
- Criteria and checklists used for work product / service evaluations (e.g. what,
when, how, who)
- Schedule for performing process evaluations (planned, actual) at selected
milestones throughout the product development life cycle
- Org chart or description identifying responsibility, objectivity, and reporting chain
of the QA function
- Quality assurance records, reports, or database
- Records of reviews or events indicating QA involvement (e.g. attendance lists,
signature)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PPQA, Page 1
Page 50
Process and Product Quality Assurance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
9:2: Internal audit: 9.2.1: a) conforms to: 1) the
organization's own requirements for its quality
management system; 2) the requirements of this
International Standard;
9:2: Internal audit: 9.2.2: b) define the audit
criteria and scope for each audit; c) select
auditors and conduct audits to ensure objectivity
and the impartiality of the audit process;
9.3: Management review: 9.3.2: Management
review inputs: c) information on the performance
and effectiveness of the quality management
system, including trends in: 3) process
performance and conformity of products and
services;
SP1.2Objectively evaluate selected work products against applicable
process descriptions, standards, and procedures.
4.2: Understanding the needs and expectations
of interested parties
The Product Owner Review verifies that
completed User Stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
4.3: Determining the scope of the quality
management system c) the products and
services of the organization.
8.1: Operational planning and control: e)
determining, maintaining and retaining
documented information to the extent
necessary: 2) to demonstrate the conformity of
products and services to their requirements.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: e) any necessary actions are taken on
problems determined during the reviews, or
verification and validation activities;
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: b) the approval of: 1)
products and services;
8.5: Production and service provision: 8.5.5:
Post-delivery activities
8.6: Release of products and services
8.6: Release of products and services: a)
evidence of conformity with the acceptance
criteria;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: a)
conformity of products and services;
Appraisal Considerations:
- “This process area primarily applies to evaluations of projects and services, but
also applies to evaluations of non-project activities and work products such as
training evaluations.”
- Refer to the Project Planning PA for more information about identifying processes
to be objectively evaluated
- Consider the PPQA PA as an enabler for GP2.9 in the context of other process
areas
- The frequency of evaluations or audits is typically defined in a quality assurance
plan. Look for evaluations performed throughout the lifecycle, not just at the end a
project or in close proximity to the assessment
- A typical implementation of this practice is through the development and use of a
quality assurance plan that may be a standalone document or incorporated into
another plan
- Depending on the culture of the organization, the process and product quality
assurance role may be performed, partially or completely, by peers, and the
quality assurance function may be embedded in the process.
Artifact Example:
- Audit reports
- Noncompliance reports
- Corrective actions
- Quality assurance plan, identifying the processes subject to evaluation, and
procedures for performing evaluations
- Applicable process descriptions, standards, and procedures
- Action items for noncompliance issues, tracked to closure
- Criteria and checklists used for work product / service evaluations (e.g. what,
when, how, who)
- Schedule for performing process evaluations (planned, actual) at selected
milestones throughout the product development life cycle
- Org chart or description identifying responsibility, objectivity, and reporting chain
of the QA function
- Quality assurance records, reports, or database
- Records of reviews or events indicating QA involvement (e.g. attendance lists,
signature)
Appraisal Considerations:
- Look for in-progress or incremental evaluations of work products and services,
and at selected milestones
- “This process area primarily applies to evaluations of projects and services, but
also applies to evaluations of non-project activities and work products such as
training evaluations.”
- Refer to the Project Planning PA for more information about identifying work
products to be objectively evaluated.
- Consider the PPQA PA as an enabler for GP2.9 in the context of other process
areas
- The frequency of evaluations or audits is typically defined in a quality assurance
plan. Look for evaluations performed throughout the lifecycle, not just at the end of
the project or in close proximity to the assessment
- A typical implementation of this practice is through the development and use of a
quality assurance plan that may be a standalone document or incorporated into
another plan
- Depending on the culture of the organization, the process and product quality
assurance role may be performed, partially or completely, by peers, and the
quality assurance function may be embedded in the process.
Artifact Example:
- Audit reports
- Noncompliance reports
- Corrective actions
- Quality assurance plan, identifying the work products and services subject to
evaluation, and procedures for performing evaluations
- Action items for noncompliance issues, tracked to closure
- Criteria and checklists used for work product evaluations (e.g. what, when, how,
who); may include sampling criteria
- Schedule for performing work product evaluations (planned, actual) at selected
milestones throughout the product development life cycle
- Org chart or description identifying responsibility, objectivity, and reporting chain
of the QA function
- Quality assurance records, reports, or database
- Records of reviews or events indicating QA involvement (e.g. attendance lists,
signature)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PPQA, Page 2
Page 51
Process and Product Quality Assurance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
9:2: Internal audit: 9.2.1: a) conforms to: 1) the
organization's own requirements for its quality
management system;
9:2: Internal audit: 9.2.2: b) define the audit
criteria and scope for each audit; c) select
auditors and conduct audits to ensure objectivity
and the impartiality of the audit process;
9.3: Management review: 9.3.2: Management
review inputs: c) information on the performance
and effectiveness of the quality management
system, including trends in: 3) process
performance and conformity of products and
services;
SG2Noncompliance issues are objectively tracked and
communicated, and resolution is ensured.
SP2.1Communicate quality issues and ensure the resolution of
noncompliance issues with the staff and managers.
5.1: Leadership and commitment: 5.1.2:
Customer focus: a) customer and applicable
statutory and regulatory requirements are
determined, understood and consistently met;
b) the risks and opportunities that can affect
conformity of products and services and the
ability to enhance customer satisfaction are
determined and addressed;
The Sprint Retrospective meeting may generate
action items to improve for the next sprint.
The Iteration Retrospective meeting may
generate action items to improve for the next
Iteration.
5.2 Policy: 5.2.2: Communicating the quality
policy: b) be communicated, understood and
applied within the organization; c) be available
to relevant interested parties, as appropriate.
The Retrospective and Problem-Solving
Workshop generates improvement stories and
features to be fed directly into the following PI
(Program Increment) Planning session. During
PI Planning, the RTE (Release Train Engineer)
helps ensure that the relevant improvement
Stories are loaded onto the Iteration plans, thus
ensuring that action will be taken and resources
5.3: Organizational roles, responsibilities, and
authorities: c) reporting on the performance of
the quality management system and on
opportunities for improvement, in particular to
top management;
7.3: Awareness: d) the implications of not
conforming with the quality management system
requirements.
7.4: Communication
8.1: Operational planning and control: The
organization shall control planned changes and
review the consequences of unintended
changes, taking action to mitigate any adverse
effects, as necessary.
Appraisal Considerations:
- Look for in-progress or incremental evaluations of work products and services,
and at selected milestones
- “This process area primarily applies to evaluations of projects and services, but
also applies to evaluations of non-project activities and work products such as
training evaluations.”
- Refer to the Project Planning PA for more information about identifying work
products to be objectively evaluated.
- Consider the PPQA PA as an enabler for GP2.9 in the context of other process
areas
- The frequency of evaluations or audits is typically defined in a quality assurance
plan. Look for evaluations performed throughout the lifecycle, not just at the end of
the project or in close proximity to the assessment
- A typical implementation of this practice is through the development and use of a
quality assurance plan that may be a standalone document or incorporated into
another plan
- Depending on the culture of the organization, the process and product quality
assurance role may be performed, partially or completely, by peers, and the
quality assurance function may be embedded in the process.
Artifact Example:
- Audit reports
- Noncompliance reports
- Corrective actions
- Quality assurance plan, identifying the work products and services subject to
evaluation, and procedures for performing evaluations
- Action items for noncompliance issues, tracked to closure
- Criteria and checklists used for work product evaluations (e.g. what, when, how,
who); may include sampling criteria
- Schedule for performing work product evaluations (planned, actual) at selected
milestones throughout the product development life cycle
- Org chart or description identifying responsibility, objectivity, and reporting chain
of the QA function
- Quality assurance records, reports, or database
- Records of reviews or events indicating QA involvement (e.g. attendance lists,
signature)
Appraisal Considerations:
- Noncompliance issues are often resolved within the project, and do not require
escalation. Assessment of the escalation path may be assessed by inspection of
applicable process descriptions and interview responses
- Look for communication of noncompliance issues to those responsible for
development, deployment, or management of applicable work products, processes
or services
- Look for recording and timely closure of noncompliance issues
- Be cautious of too many waivers being issued to resolve noncompliance.
Artifact Example:
- Corrective action reports
- Audit reports
- Quality trends
- Action items for noncompliance issues, tracked to closure
- Revised work products, services, standards and procedures, or waivers issued to
resolve noncompliance issues
- Reports or briefings communicating noncompliance issues to relevant
stakeholders
- Evidence of reviews held periodically to receive and act upon noncompliance
issues
- Quality metrics and trend analyses
- Tracking system or database for noncompliance issues.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PPQA, Page 3
Page 52
Process and Product Quality Assurance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: e) any necessary actions are taken on
problems determined during the reviews, or
verification and validation activities;
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: d) the actions taken to prevent
adverse impacts.
8.5: Control of production and service provision:
8.5.3: Property belonging to customers or
external providers
8.7: Control of nonconforming outputs: 8.7.1: a)
correction;
8.7: Control of nonconforming outputs: 8.7.2: a)
describes the nonconformity; b) describes the
actions taken;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: c) the
performance and effectiveness of the quality
management system;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: g) the
need for improvements to the quality
management system.
9:2: Internal audit: 9.2.2: d) ensure that the
results of the audits are reported to relevant
management;
9:2: Internal audit: 9.2.2: e) take appropriate
correction and corrective actions without undue
delay;
9.3: Management review: 9.3.2: Management
review inputs: c) information on the performance
and effectiveness of the quality management
system, including trends in: 4) nonconformities
and corrective actions; 5) monitoring and
measurement results;
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 1) take action to control and correct
it; c) implement any action needed;
SP2.2 Establish and maintain records of quality assurance activities.
8.1: Operational planning and control: The
organization shall control planned changes and
review the consequences of unintended
changes, taking action to mitigate any adverse
effects, as necessary.
Sprint Retrospective meeting minutes or action
items may be an output from the meeting.
The Iteration Retrospective meeting may
generate action items or meeting minutes as an
output from the meeting.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: f) documented information of these
activities is retained.8.6: Release of products and services: a)
evidence of conformity with the acceptance
criteria;
Appraisal Considerations:
- Noncompliance issues are often resolved within the project, and do not require
escalation. Assessment of the escalation path may be assessed by inspection of
applicable process descriptions and interview responses
- Look for communication of noncompliance issues to those responsible for
development, deployment, or management of applicable work products, processes
or services
- Look for recording and timely closure of noncompliance issues
- Be cautious of too many waivers being issued to resolve noncompliance.
Artifact Example:
- Corrective action reports
- Audit reports
- Quality trends
- Action items for noncompliance issues, tracked to closure
- Revised work products, services, standards and procedures, or waivers issued to
resolve noncompliance issues
- Reports or briefings communicating noncompliance issues to relevant
stakeholders
- Evidence of reviews held periodically to receive and act upon noncompliance
issues
- Quality metrics and trend analyses
- Tracking system or database for noncompliance issues.
Appraisal Considerations:
- Look for recording of PPQA activities in sufficient detail such that status and
results are known.
Artifact Example:
- Audit logs
- Quality assurance reports]
- Records of quality assurance activities
- Status of corrective actions
- Quality trends
- Noncompliance actions, reports, logs, or database
- Completed evaluation checklists
- Schedule for performing process, product and service evaluations (planned,
actual)
- Records of reviews or events indicating QA involvement (e.g. attendance lists,
signature)
- Metrics or analyses used for quality assurance of processes and work products.Last updated 8/20/17
This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PPQA, Page 4
Page 53
Process and Product Quality Assurance
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.7: Control of nonconforming outputs: 8.7.1
8.7: Control of nonconforming outputs: 8.7.2: b)
describes the actions taken;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: b) the
degree of customer satisfaction;
9:2: Internal audit: 9.2.2: f) retain documented
information as evidence of the implementation
of the audit programme and the audit results.
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 1) take action to control and correct
it;
Appraisal Considerations:
- Look for recording of PPQA activities in sufficient detail such that status and
results are known.
Artifact Example:
- Audit logs
- Quality assurance reports]
- Records of quality assurance activities
- Status of corrective actions
- Quality trends
- Noncompliance actions, reports, logs, or database
- Completed evaluation checklists
- Schedule for performing process, product and service evaluations (planned,
actual)
- Records of reviews or events indicating QA involvement (e.g. attendance lists,
signature)
- Metrics or analyses used for quality assurance of processes and work products.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PPQA, Page 5
Page 54
Quantitative Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1 Preparation for quantitative management is conducted.
SP1.1Establish and maintain the quality and process performance
objectives for the work.
5.1: Leadership and commitment: 5.1.1:
General: b) ensuring that the quality policy and
quality objectives are established for the quality
management system and are compatible with
the context and strategic direction of the
organization;
The scrum team defines and agrees upon a
Definition of Done to use to determine that a
requirement has been completed.
6.2: Quality objectives and planning to achieve
them: 6.2.1: b) be measurable;
The organization and scrum team must
determine their quantitative quality and process
performance objectives and maintain those
objectives based on past performance data.
8.1: Operational planning and control: b)
establishing criteria for: 1) the processes;
The Sprint Retrospective may create changes to
the quality and process performance objectives
based on the experiences of the past sprint.
The Iteration Retrospective may create changes
to the quality and process performance
objectives based on the experiences of the past
Iteration.
8.6: Release of products and services
During the PI (Program Increment) Inspect &
Adapt workshop, the teams review the
quantitative Metrics they have agreed to collect
and use the Program Predictability Measure to
determine the actual business value achieved
against the planned business value for each
SP1.2
Using statistical and other quantitative techniques, compose a
defined process that enables the work to achieve its quality and
process performance objectives.
8.1: Operational planning and control: b)
establishing criteria for: 1) the processes;
The Agile process (ScrumXP, Kanban, SAFe®)
defines the lifecycle used by the organization to
achieve project quality and process performance
objectives.
“Built-in Quality – Large systems have more
economic sensitivity to quality than to the
features and subsystems that define them.
SAFe®’s built-in quality practices help every
team understand and ensure that each solution
element, at every increment, achieves
appropriate quality standards throughout
development. The result is fast, continuous flow
with a minimum of delays due to rework, high
value delivery velocity, and the highest levels of
customer satisfaction.”
– SAFe® Core Values
SP1.3
Select subprocesses and attributes critical to evaluating
performance and that help to achieve the quality and process
performance objectives for the work.
8.1: Operational planning and control: b)
establishing criteria for: 1) the processes;
The number of defects found in the product,
whether build defects found in testing, defects
found by the Product Owner in User Acceptance
Testing, or defects found after product release,
can be used to track the quality of the product.
Appraisal Considerations:
- The project specific subprocess(es) are defined by reviewing the organization's
project knowledge base.
Artifact Example:
- Criteria used to evaluate alternatives for the work
- Alternative subprocesses
- Subprocesses to be included in the defined process
- Assessment of risk of not achieving the objectives for the work.
- Organizational Quality Management Plan
- Work Plan
- Minutes from metrics analysis meeting showing QPM planning and monitoring
Appraisal Considerations:
- The project's overall plan should identify those metrics that are to be controlled
statistically.
Artifact Example:
- Criteria used to select subprocesses that are key contributors to achieving the
objectives for the work
- Selected subprocesses
- Attributes of selected subprocesses that help in predicting future work
performance
- Work Plan
- Documented risks and actions related to achieving quality and process
performance objectives
- Minutes from metrics analysis meeting showing QPM planning and monitoring
Appraisal Considerations:
- The measurement objectives for the project need to be defined.
Artifact Example:
- The quality and process-performance objectives for the work.
- Work Plan
- Organizational Quality Management Plan
- Organizational business, quality and process-performance objectives
- Procedures on project planning and/or metrics
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. QPM, Page 1
Page 55
Quantitative Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
During the PI (Program Increment) Inspect &
Adapt workshop, the teams review the
quantitative Metrics they have agreed to collect
and use the Program Predictability Measure to
determine the actual business value achieved
against the planned business value for each
team’s PI Objectives.
SP1.4Select measures and analytic techniques to be used in quantitative
management.
8.1: Operational planning and control: b)
establishing criteria for: 1) the processes;
The Sprint Burndown Chart shows the status of
the work that the development team has
completed and tracks actual progress to the
estimated schedule.
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
The number of defects found in the product,
whether build defects found in testing, defects
found by the Product Owner in User Acceptance
Testing, or defects found after product release,
can be used to track the quality of the product.
WSJF (Weighted Shortest Job First) is a metric
used to sequence jobs based on the Cost of
Delay (the impact of User-Business Value, Time
Criticality, and Risk Reduction (and/or
Opportunity Enablement)).
During the PI (Program Increment) Inspect &
Adapt workshop, the teams review the
quantitative Metrics they have agreed to collect
and use the Program Predictability Measure to
determine the actual business value achieved
against the planned business value for each
team’s PI Objectives.
SG2 The work is quantitatively managed.
SP2.1Monitor the performance of selected subprocesses using
statistical and other quantitative techniques.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: a) what needs to be
monitored and measured; b) the methods for
monitoring, measurement, analysis and
evaluation needed to ensure valid results;
The Agile approach of inspecting and adapting
processes means that action items implemented
from the Sprint Retrospective meeting should be
evaluated for their effect on process
performance.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: a)
conformity of products and services; c) the
performance and effectiveness of the quality
management system; g) the need for
improvements to the quality management
system.
Velocity is used to estimate how much
functionality the development team can deliver
in a given amount of time based on the average
number of user story points the team completes
per sprint.
Appraisal Considerations:
- None
Artifact Example:
- Natural bounds of process performance for each selected subprocess attribute
- The actions needed to address deficiencies in the process stability of each
selected subprocess
- Procedures for project tracking / monitoring and corrective action
- Documented risks and actions related to achieving quality and process
performance objectives
- Minutes from metrics analysis meeting showing QPM monitoring
Appraisal Considerations:
- During the project planning phase, the identification of metrics and the metric
analysis technique and frequency should be identified.
Artifact Example:
- Definitions of measures and analytic techniques to be in quantitative
management
- Traceability of measures back to the quality and process-performance objectives
- Quality and process-performance objectives that are expressed for selected
subprocesses and their attributes
- Process performance baselines and models for use by the work group.
- Procedures for Project Planning and Metrics
- Work Plan
- Measure selection criteria
Appraisal Considerations:
- The project's overall plan should identify those metrics that are to be controlled
statistically.
Artifact Example:
- Criteria used to select subprocesses that are key contributors to achieving the
objectives for the work
- Selected subprocesses
- Attributes of selected subprocesses that help in predicting future work
performance
- Work Plan
- Documented risks and actions related to achieving quality and process
performance objectives
- Minutes from metrics analysis meeting showing QPM planning and monitoring
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. QPM, Page 2
Page 56
Quantitative Project Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
During the PI (Program Increment) Inspect &
Adapt workshop, the teams review the
quantitative Metrics they have agreed to collect
and use the Program Predictability Measure to
determine the actual business value achieved
against the planned business value for each
team’s PI Objectives.
SP2.2
Manage the work using statistical and other quantitative
techniques to determine whether or not the quality and process
performance objectives for the work will be satisfied.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General: a) what needs to be
monitored and measured; b) the methods for
monitoring, measurement, analysis and
evaluation needed to ensure valid results;
The Sprint Burndown Chart shows the status of
the work that the development team has
completed and tracks actual progress to the
estimated schedule.
The Sprint Burndown Chart shows the status of
the work that the development team has
completed and tracks actual progress to the
estimated schedule.
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: a)
conformity of products and services; c) the
performance and effectiveness of the quality
management system; g) the need for
improvements to the quality management
system.
During the PI (Program Increment) Inspect &
Adapt workshop, the teams hold a Problem-
Solving and Retrospective workshop to identify
a small number of significant problems that
teams decide to address.
SP2.3
Perform root cause analysis of selected issues to address
deficiencies in achieving the work group's quality and process
performance objectives.
10.2: Nonconformity and corrective action:
10.2.1: a) react to the nonconformity and, as
applicable: 2) deal with the consequences; b)
evaluate the need for action to eliminate the
cause(s) of the nonconformity, in order that it
does not recur or occur elsewhere, by: 2)
determining the causes of the nonconformity;
The Agile approach of inspecting and adapting
processes means that action items implemented
from the Sprint Retrospective meeting should be
evaluated for their effect on process
performance.
The Iteration Retrospective evaluates what went
well and what did not go well in the last sprint,
and what they can change to improve the next
Iteration.
During the PI (Program Increment) Inspect &
Adapt workshop, the teams hold a Problem-
Solving and Retrospective workshop to identify
a small number of significant problems that
teams decide to address.
Appraisal Considerations:
- None
Artifact Example:
- Natural bounds of process performance for each selected subprocess attribute
- The actions needed to address deficiencies in the process stability of each
selected subprocess
- Procedures for project tracking / monitoring and corrective action
- Documented risks and actions related to achieving quality and process
performance objectives
- Minutes from metrics analysis meeting showing QPM monitoring
Appraisal Considerations:
- None
Artifact Examples:
- Predictions of outcomes to be achieved relative to the quality and process-
performance objectives
- Visual displays and data tabulations for other subprocesses, which support
quantitative management
- Assessment of risks of not achieving the quality and process-performance
objectives
- Actions needed to address deficiencies in achieving work objectives
Appraisal Considerations:
- None
Artifact Example:
- Subprocess and performance measurements and analyses (including statistical
analyses) recorded in the organization’s measurement repository
- Visual displays of data used to understand subprocess and performance and
performance trends
- Identified root causes and potential actions to take
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. QPM, Page 3
Page 57
Requirements Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Requirements are managed and inconsistencies with
plans and work products are identified.
SP1.1Develop an understanding with the requirements providers on the
meaning of the requirements.
5.3: Organizational roles, responsibilities, and
authorities: a) ensuring that the quality
management system conforms to the
requirements of this International Standard;
The Product Vision Statement articulates the
goals for the project and must be understood by
the project stakeholders, development team,
and the Scrum Master.
All team members must understand the Solution
Vision, and each level of SAFe® develops their
own Vision of how they will help meet higher-
level objectives.
6.2: Quality objectives and planning to achieve
them: 6.2.1: c) take into account applicable
requirements;
The Product Roadmap / Product Backlog
identifies and groups requirements for the
product and defines high-level estimates for
effort, priority, and time frames.
The SAFe® Roadmap consists of a the
upcoming planned and committed Program
Increment (PIs) and the next planned PIs, with
upcoming Milestones indicated.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
Requirements may be broken down
(decomposed) into Themes, Features, Epic
User Stories, User Stories, or Tasks, which
describe the requirements in terms of its value
to the end user.
Functional system behavior is described and
broken down, from Epics to Capabilities,
Features, and then Stories at the Portfolio,
Value Stream, Program, and Team levels,
respectively.
8.5: Production and service provision: 8.5.2:
Identification and traceability
SP1.2 Obtain commitment to requirements from participants.
5.3: Organizational roles, responsibilities, and
authorities: a) ensuring that the quality
management system conforms to the
requirements of this International Standard;
The Product Vision Statement must be
understood by the project stakeholders,
development team, and the Scrum Master.
All team members must understand the Solution
Vision, and each level of SAFe® develops their
own Vision of how they will help meet higher-
level objectives.
The Product Roadmap / Product Backlog may
be created with input from stakeholders and the
development team.
User stories are created with input from
stakeholders and the development team.
Story Points estimate the value and effort for
each Story.
Sprint Planning is performed together by the
Product Owner, Scrum Master, and the
development team.
Iteration Planning is performed together by the
Product Owner, Scrum Master, and the
development team.
SP1.3 Manage changes to requirements as they evolve.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.4:Changes to requirements for
products and services
The Product Roadmap / Product Backlog is a
living document to which requirements can be
added or changed.
The Roadmap is developed and updated by
Solution and Product Management as the Vision
and delivery strategy evolve.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
Sprint Planning decides whether a new
requirement should be a part of the sprint.
New requirements are elaborated into Epics,
Capabilities, Features, or Stories and added to
the Portfolio, Value Stream, Program, and
Team Backlogs, respectively.
8.5: Production and service provision: 8.5.2:
Identification and traceability
SP1.4Maintain bidirectional traceability among requirements and work
products.
Appraisal Considerations: Consider existence of requirements at multiple levels
(e.g., to service and service system requirements.).
Artifact Example:
- Lists of criteria for distinguishing appropriate requirements providers
- Criteria for evaluation and acceptance of requirements
- Results of analyses against criteria
- A set of approved requirements
- Service agreement
- Evidence of early allocation of service requirements to service system
requirements
- A list or characterization of requirements providers authorized to provide
direction
Appraisal Considerations:
- Ensure this is performed not only for the initial requirements set, but also for
subsequent changes
- Consider how commitments to requirements are obtained at multiple levels; this
may involve different stakeholders at each level.
- The intent of this practice includes consideration of impact upon project
stakeholders prior to commitment to requirements (e.g., plans, estimates,
schedules).
Artifact Example:
- Requirements impact assessments
- Documented commitments to requirements and requirements changes
- Requirements review artifacts
- Requirements change request logs and/ or database reports
Appraisal Considerations:
- The scope of REQM is to identify and assess the impact of requirements
changes, but does not including development and incorporation of revisions.
Artifact Example:
- Requirements change request
- Requirements change impact reports
- Requirements status
- Requirements database
- Requirements reports with attributes including current state (e.g., approval,
source, rationale, revision history, impact)
- Requirements change reviews artifacts
- Revisions to service system and/or work products resulting from changed
requirements
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. REQM, Page 1
Page 58
Requirements Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.7: Control of nonconforming outputs: 8.7.1
A card-based User Story system typically has
the requirements on the front side of the card,
and the verification steps to confirm the work
product meets the requirement on the back side
of the card.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
The Sprint Burndown Chart shows the status of
the work that the development team has
completed and tracks actual progress to the
estimated schedule.
Agile project management tools are used to
track the status of stories, defects, test cases,
estimates, actuals, burndowns, and more.
8.5: Production and service provision: 8.5.2:
Identification and traceability
SP1.5Ensure that plans and work products remain aligned with
requirements.
6.2: Quality objectives and planning to achieve
them: 6.2.1: d) be relevant to conformity of
products and services and to enhancement of
customer satisfaction;
Daily Stand-up Meetings identify issues. Daily Stand-up Meetings identify issues.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.4:Changes to requirements for
products and services
The Sprint Burndown Chart shows the status of
the work that the development team has
completed and tracks actual progress to the
estimated schedule.
Agile project management tools are used to
track the status of stories, defects, test cases,
estimates, actuals, burndowns, and more.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
The Product Owner Review verifies that
completed user stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
Appraisal Considerations:
- Ensure that both vertical and horizontal traceability are included (e.g., across
functions or interfaces)
- (How do we assess traceability of requirements to “project plans”? This is
probably more implicit than explicit, and applies to plans such as test plans, V&V
plans, etc. See PP PA for project plans that might be affected. The assessment
team must reach consensus on how this is to be assessed for the organization.)
Artifact Example:
- Requirements traceability matrix
- Requirements tracking system
- Criteria and completed checklists and minutes for review of requirements
traceability
- Revision and maintenance of requirements traceability across the lifecycle
- Listings of allocated service requirements included in reviews of project plans
and work products across the lifecycle.
- Requirements mappings used to support impact assessments
Appraisal Considerations:
-The scope of the REQM PA is simply to identify, but not correct, requirements
issues that must be resolved.
Artifact Examples:
- Documentation of identified requirements inconsistencies including sources,
conditions, rationales.
- Corrective action requirements
- Corrective action requests initiated as a result of inconsistencies between
requirements and plans / work products
- Completed checklists, forms, logs, action items, or minutes substantiation
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. REQM, Page 2
Page 59
Risk Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1 Preparation for risk management is conducted.SP1.1 Determine risk sources and categories.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed;
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
6.1: Actions to address risks and opportunities:
6.1.1: c) prevent, or reduce, undesired effects;
Program-level risks and impediments are
categorized as resolved, owned, accepted, or
mitigated (ROAM).
SP1.2Define parameters used to analyze and categorize risks and to
control the risk management effort.
4.1: Understanding the organization and its
context
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
Risks are identified during the Team Breakout
and Plan Review segments of PI Planning and
categorized during the Program Risks segment
of the PI Planning meeting.
SP1.3Establish and maintain the strategy to be used for risk
management.
5.1: Leadership and commitment: 5.1.1:
General: d) promoting the use of the process
approach and risk-based thinking;
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed;
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
Appraisal Considerations:
- The intent of this practice is to define a structured framework for the
identification, assessment, and management of risks.
- “Risk categories reflect the ‘bins’ for collecting and organizing risks.”
- This may include an organizational standard risk taxonomy, which might be
tailored for application to the specific projects. The initial set of identified sources
and categories may be refined as the project progresses.
- The risk sources and categories may be contained in a risk management plan or
inherent in a risk management tool.
Artifact Example:
- Risk sources lists (external and internal)
- Risk categories list
- Risk taxonomy or hierarchy (e.g., risk classes, elements, attributes).
- Risk management plan and procedures.
- Risk management tool or database.
- Risk categorization guidelines (e.g., source, impact types).
Appraisal Considerations:
- Risk priority may be defined as a combination of risk probability and severity
- These risk parameters may be defined at the organizational level, or might be
tailored for application to specific projects.
- Thresholds can be defined separately for each risk category, or could be defined
on a project-wide basis (e.g., variance thresholds)
- Risk parameters and thresholds may be defined and applied on a quantitative or
qualitative basis.
Artifact Example:
- Risk evaluation, categorization, and prioritization criteria
- Risk management requirements (control and approval levels, reassessment
intervals, etc.)
- Risk management plan and procedures
- Risk management tool or database
- Defined ranges and parameters for risk evaluation, categorization, and
prioritization, such as risk likelihood (probability), consequence (severity)
- Defined thresholds (e.g., control points, scoping boundary conditions,
exclusions, triggers) and criteria for taking action
Appraisal Considerations:
- “The risk management strategy is often documented in an organizational or
project risk management plan.” This may include the risk sources and categories
(SP1.1) and risk parameters (SP1.2) to be used.
- The risk management plan may be a standalone document, or its content
reflected in other existing project plans. See model for additional details on typical
contents of the risk management strategy.
- The SPs associated with SG1 establish the planning for risk management,
enactment of which can be assessed in the remaining practices. Correspondingly,
work products and artifacts produced by SG2/SG3 SPs can be used to
substantiate the establishment and maintenance of the SG1 practices.
Artifact Example:
- Project risk management strategy
- Risk management plan
- Revisions to the risk management strategy
- Evidence of reviews of the risk management strategy held with project and/or
service stakeholders (e.g., signature approval, minutes, action items)
- Measures identified for monitoring risk status
- Risk management procedures and tools
- Description and application of risk mitigation techniques (prototyping, simulation,
etc.)Last updated 8/20/17
This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RSKM, Page 1
Page 60
Risk Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
9.3: Management review: 9.3.2: Management
review inputs: e) the effectiveness of actions
taken to address risks and opportunities;
SAFe® defines the practices for identifying and
categorizing risks (using ROAM) and the
processes which use risk management
practices (PI Planning).
SG2Risks are identified and analyzed to determine their
relative importance.SP2.1 Identify and document risks.
6.1: Actions to address risks and opportunities:
6.1.1: c) prevent, or reduce, undesired effects;
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
Risks are identified during the Team Breakout
and Plan Review segments of PI Planning and
categorized during the Program Risks segment
of the PI Planning meeting.
SP2.2Evaluate and categorize each identified risk using defined risk
categories and parameters, and determine its relative priority.
6.1: Actions to address risks and opportunities:
6.1.1: c) prevent, or reduce, undesired effects;
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
9.3: Management review: 9.3.2: Management
review inputs: e) the effectiveness of actions
taken to address risks and opportunities;
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
Risks are identified during the Team Breakout
and Plan Review segments of PI Planning and
categorized during the Program Risks segment
of the PI Planning meeting.
Appraisal Considerations:
- Refer to PP SP2.2-1 for additional information about identifying project risks. The
risk sources, categories, and parameters defined here in SP1.1 and SP1.2 provide
a structured mechanism for the systematic identification of risks. This is a potential
distinction from risk identification in PP SP2.2, which may be performed more
informally.
- Ensure coverage of risks (cost, schedule, performance) across appropriate
product life-cycle phases; see SubP.1 for examples and guidance.
- A risk management tool or database may be used to capture and manage
identified risks.
- Look to see that this is an ongoing activity performed across the project lifecycle,
i.e., not just a one-time identification of risks, but reviewed and maintained over
time.
Artifact Example:
- List of identified risks, including the context, conditions, and consequences for
occurrence
- Revisions to list of identified risks
- Structured risk statements
- Risk assessment results or evidence of occurrence
- Risk taxonomy-based questionnaire interviews
Appraisal Considerations:
- Risks are evaluated, categorized, and analyzed according to the categories and
parameters defined in SP1.1 and SP1.2.
- Risks may be evaluated using quantitative or qualitative criteria (ref. SP1.2)
- Like risk identification, these are not simply one-time activities, and should be
continuously applied across the product life cycle.
- Relative priority is typically determined using a combination of assigned risk
parameters (e.g., severity, likelihood, timeframe). This should be described in the
risk management plan.
- Different risk management terminology may be commonly used within the
organization. Consider typical synonyms in determining implementation of this
practice; e.g. risk assessment, risk analysis, likelihood vs. probability,
consequence vs. impact, risk exposure vs. risk priority.
Artifact Example:
- List of risks, with a priority assigned to each risk
- Categorization and parameter values of identified risks
- Aggregated and consolidated set of risks, with cause and effect relationships
identified between related risks
- Project reviews or briefings of risks and risk parameters
- Criteria used to quantify risks and assign risk parameters.
- Derived measures for identified risks (e.g., risk exposure)
Appraisal Considerations:
- “The risk management strategy is often documented in an organizational or
project risk management plan.” This may include the risk sources and categories
(SP1.1) and risk parameters (SP1.2) to be used.
- The risk management plan may be a standalone document, or its content
reflected in other existing project plans. See model for additional details on typical
contents of the risk management strategy.
- The SPs associated with SG1 establish the planning for risk management,
enactment of which can be assessed in the remaining practices. Correspondingly,
work products and artifacts produced by SG2/SG3 SPs can be used to
substantiate the establishment and maintenance of the SG1 practices.
Artifact Example:
- Project risk management strategy
- Risk management plan
- Revisions to the risk management strategy
- Evidence of reviews of the risk management strategy held with project and/or
service stakeholders (e.g., signature approval, minutes, action items)
- Measures identified for monitoring risk status
- Risk management procedures and tools
- Description and application of risk mitigation techniques (prototyping, simulation,
etc.)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RSKM, Page 2
Page 61
Risk Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG3Risks are handled and mitigated as appropriate to reduce
adverse impacts on achieving objectives.
SP3.1Develop a risk mitigation plan in accordance with the risk
management strategy.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed;
The Product Owner and the development team
may create a list of acceptable risks to go with
their agreed-upon Definition of Done.
6.1: Actions to address risks and opportunities:
6.1.2: a) actions to address these risks and
opportunities;
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
8.2: Requirements for products and services:
8.2.1: Customer communication: e) establishing
specific requirements for contingency actions,
when relevant.
Program-level risks and impediments are
categorized as resolved, owned, accepted, or
mitigated (ROAM).
9.3: Management review: 9.3.2: Management
review inputs: e) the effectiveness of actions
taken to address risks and opportunities;
During Iteration Planning, the Product Owner
may rerank Stories based on risk in addition to
other factors.
SP3.2Monitor the status of each risk periodically and implement the risk
mitigation plan as appropriate.
5.1: Leadership and commitment: 5.1.2:
Customer focus: b) the risks and opportunities
that can affect conformity of products and
services and the ability to enhance customer
satisfaction are determined and addressed;
The Agile practice of self-managing teams
leaves it up to the scrum team to manage and
monitor risks.
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: d) the actions taken to prevent
adverse impacts;
The Daily Stand-up Meeting may discuss new
risks or action plans for mitigating risks.
The Daily Stand-up Meeting may discuss new
risks or action plans for mitigating risks.
During Iteration Planning, the Product Owner
may rerank Stories based on risk in addition to
other factors.
Appraisal Considerations:
- Risk monitoring and status reviews of all risks should be performed at the
intervals defined by the risk management strategy. Monitoring should continue
even after initiation of risk mitigation activities
- Inspect risk items to ensure deployment of mitigation plans upon exceeding
defined thresholds or criteria.
- Look for implementation of risk mitigation plans, such as commitment of
resources invested toward risk mitigation (e.g. staffing, schedule, tools).
Artifact Example:
- Updated lists of risk status
- Updated assessments of risk likelihood, consequence, and thresholds
- Implemented risk mitigation actions or contingency plans
- Updated lists of risk-handling options
- Updated list of actions taken to handle risks
- Risk mitigation plans
- Risk status reports, analyses, performance measures, trending.
- Evidence of risk management status reviews (periodic and event-driven)
- Newly identified risks
- Risk handling actions, tracked to closure.
Appraisal Considerations:
- See SP1.3 for components of the risk management strategy applicable to risk
mitigation, e.g., parameters, thresholds, methods, tools.
- “A critical component of a risk mitigation plan is to develop alternative courses of
action, workarounds, and fallback positions, with a recommended course of action
for each critical risk.” See model for typical risk handling options (e.g., avoidance,
control, transfer, monitor, acceptance).
- Not all risks require mitigation. “Mitigation plans are often generated only for
selected risks of high consequence; other risks may be accepted and simply
monitored.”
- Mitigation plans in this context include risk reduction plans and/or contingency
plans. Different terms may be used in the organization, such as risk handling or
risk action plans.
- Thresholds and triggers for deployment of mitigation plans may be contained in
the risk management strategy/plan, or may be specific to individual risk items.
- Look for the realistic budgeting and allocation of resources to mitigation plans;
plans without resources are not meaningful.
- Look for ongoing risk monitoring and risk mitigation across the project life cycle.
Artifact Example:
- Risk mitigation plans
- Contingency plans
- Documented handling options for each identified risk
- List of those responsible for tracking and addressing each risk
- Risk levels and thresholds defined to trigger deployment of risk mitigation plans
- Risk mitigation cost/benefit tradeoff analyses
- Management reserve budget allocation for deployment of risk mitigation plans
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RSKM, Page 3
Page 62
Supplier Agreement Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Agreements with the suppliers are established and
maintained.
SP1.1Determine the type of acquisition for each product or product
component to be acquired.
7.1: Resources: 7.1.1: General: b) what needs
to be obtained from external providers.
If the development team determines that
acquisition is needed, the Scrum Master first
checks that the product/service is not available
internally before working with the development
team and Product Owner to procure the
product/service. Records of evaluating and
comparing COTS products and services may be
generated and purchases are reflected in the
project budget.
8.4: Control of externally provided processes,
products and services: 8.4.1: General: a)
products and services from external providers
are intended for incorporation into the
organization's own products and services; b)
products and services are provided directly to
the customer(s) by external providers on behalf
of the organization; c) a process, or part of a
process, is provided by an external provider as a
result of a decision by the organization.
8.5: Production and service provision: 8.5.3:
Property belonging to customers or external
providers
SP1.2Select suppliers based on an evaluation of their ability to meet the
specified requirements and established criteria.
8.4: Control of externally provided processes,
products and services: 8.4.1: General: a)
products and services from external providers
are intended for incorporation into the
organization's own products and services; b)
products and services are provided directly to
the customer(s) by external providers on behalf
of the organization; c) a process, or part of a
process, is provided by an external provider as a
result of a decision by the organization.
If the development team determines that
acquisition is needed, the Scrum Master first
checks that the product/service is not available
internally before working with the development
team and Product Owner to procure the
product/service. Records of evaluating and
comparing COTS products and services may be
generated and purchases are reflected in the
project budget.
SAFe® suggests having multiple participants
from engineering and purchasing to be involved
to supplier selection.
8.4: Control of externally provided processes,
products and services: 8.4.2: Type and extent of
control: a) ensure that externally provided
processes remain within the control of its quality
management system; b) define both the controls
that it intends to apply to an external provider
and those it intends to apply to the resulting
output;
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: c) competence, including any
required qualification of persons;
Appraisal Considerations:
- Look for evidence that the “established criteria” were identified in advance and
actually used to evaluate suppliers
- Most procurement-specific data will be source selection sensitive and may not
available for inspection. It may be necessary to use alternative data, such as blank
evaluation forms and summary briefings or supplement with interview observations
- Recognize that non-technical factors may be applicable to supplier selection
(strategic partnerships, market positioning, political, etc.). This may result in
selection of suppliers that are neither best technical nor lowest cost, but should
still be reflected in the evaluation criteria and factors used for supplier selection.
Artifact Example:
- Rationale for selection of suppliers
- Evaluation criteria
- Supplier evaluation results
- List of candidate suppliers
- Preferred supplier list
- Advantages and disadvantages of candidate suppliers
- Solicitation materials and requirements
- Requirements allocation to the product or service to be acquired
- Procurement documentation (e.g., tech spec, SOW, interfaces, solicitation,
proposals, etc.)
- Supplier surveys
- Analysis of acquisition risks and best value supplier
- Source selection decision
Appraisal Considerations:
- “This process area primarily applies to the acquisition of products and product
components that are delivered to the project’s customer.” This PA is not directly
applicable to non-deliverable products or labor subcontracts (i.e., hiring
contractors to supplement the acquirer’s staff in an integrated project team)
- The entry to this PA assumes that a decision to acquire the product or service
externally has already been made (i.e., requirements and make/buy analysis have
been performed in Engineering PAs); SAM deals with managing the acquisition
from suppliers
- See CMMI glossary for definition of “supplier”· Example acquisition types include:
COTS products; obtaining products or services through a contractual agreement
(or subcontract); in-house/3rd party development; customer-furnished products; co-
development, or some combination of above.
Artifact Example:
- List of the acquisition types that will be used for all products and product
components to be acquired
- Make/buy analysis or trade study with product acquisition options
- Management authorization to proceed with acquisition of a product or service
- System architecture/design documentation identifying products or components to
be acquired (e.g., non-developmental items)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. SAM, Page 1
Page 63
Supplier Agreement Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: f) the
performance of external providers;
9.3: Management review: 9.3.2: Management
review inputs: c) information on the performance
and effectiveness of the quality management
system, including trends in: 7) the performance
of external providers;
SP1.3 Establish and maintain supplier agreements.
SG2Agreements with suppliers are satisfied by both the work
group and the supplier.
SP2.1Perform activities with the supplier as specified in the supplier
agreement.
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: d) the external providers'
interactions with the organization; e) control and
monitoring of the external providers'
performance to be applied by the organization;
The Scrum Master works with the legal or
procurement department to create a contract
with the vendor. The Scrum Master is
responsible for maintaining a close relationship
with the vendor.
SAFe® emphasizes the development of long-
lasting, cooperative, adaptive, and transparent
relationships with suppliers over short-term, low-
value, distant relationships. Collaboration
occurs across all levels of SAFe®.
Appraisal Considerations:
- Look for evidence that the “established criteria” were identified in advance and
actually used to evaluate suppliers
- Most procurement-specific data will be source selection sensitive and may not
available for inspection. It may be necessary to use alternative data, such as blank
evaluation forms and summary briefings or supplement with interview observations
- Recognize that non-technical factors may be applicable to supplier selection
(strategic partnerships, market positioning, political, etc.). This may result in
selection of suppliers that are neither best technical nor lowest cost, but should
still be reflected in the evaluation criteria and factors used for supplier selection.
Artifact Example:
- Rationale for selection of suppliers
- Evaluation criteria
- Supplier evaluation results
- List of candidate suppliers
- Preferred supplier list
- Advantages and disadvantages of candidate suppliers
- Solicitation materials and requirements
- Requirements allocation to the product or service to be acquired
- Procurement documentation (e.g., tech spec, SOW, interfaces, solicitation,
proposals, etc.)
- Supplier surveys
- Analysis of acquisition risks and best value supplier
- Source selection decision
Appraisal Considerations:
- “A formal agreement is any legal agreement between the organization
(representing the project) and the supplier.”; e.g., contract, license, MOA. The type
of agreement may vary according to the product acquisition type (subcontracted
custom product, COTS product, customer-furnished product, service, service
component, etc.)
- See model (SubP.3) for typical contents of the supplier agreement, but recognize
the contents and formality may vary according to the type of acquisition (size, cost,
complexity, risk, COTS, etc.)
- Investigate how the formal agreement is “maintained”; e.g., contractual revisions,
renegotiations, impact assessment, interfaces, replanning.
Artifact Example:
- Documented formal supplier agreement, with approved revisions as necessary.
(see typical work products for examples)
- Statements of Work
- Contracts
- Memoranda of agreement
- Licensing agreement
- Negotiated contractual terms, conditions, and constraints (e.g., deliverables,
requirements, schedule, budget, standards, facilities, acceptance criteria)
- Defined parameters, criteria, and objectives for evaluating supplier performance
- Acquirer plans to monitor supplier progress and product or service quality (e.g.,
quality plans, IV&V plans)
- Integration of supplier products and schedules into acquirer plans (e.g.,
milestones, interfaces, dependencies, environment, testing, etc.)
- Acquirer impact assessment and revision to project plans, as necessary
- Supplier Work Breakdown Structure
- Issues or action items relating to definition or revision of the supplier agreement.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. SAM, Page 2
Page 64
Supplier Agreement Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.1: Operational planning and control: The
organization shall ensure that outsourced
processes are controlled.
Vendors team members may be invited to Sprint
Reviews or even Daily Scrum meetings if they
are integrated with the scrum team. If the vendor
follows Agile development practices, their sprint
schedule shall match the buyer’s sprint
schedule. If the vendor follows traditional
waterfall development practices, the Scrum
Master may need to intervene if the vendor’s
processes or timeline becomes a roadblock for
the scrum team.
Lean-Agile Suppliers are treated as an Agile
Release Train and work in the same cadence as
the other ARTs. They also participate in
Planning, Demos, and Inspect & Adapt
meetings. As a customer of the Supplier, the
organization will also have to participate in the
Supplier's development value stream. Suppliers
using traditional development practices must
also participate in Planning, Demos, and Inspect
& Adapt meetings, even if they only have
documents and not working systems. SAFe®
organizations should not expect them to deliver
incrementally and will have to expect a slower
response time to changes and to spend more
time up-front on the design.
8.4: Control of externally provided processes,
products and services: 8.4.2: Type and extent of
control: c) take into consideration: 2) the
effectiveness of the controls applied by the
external provider;
Collaboration occurs across all levels of SAFe®.
The organization shares its Strategic Themes
with the Supplier. Solution Managers
continuously collaborate with Suppliers to write
capabilities and decompose them into Features.
Solution Architects/Engineering work with their
Supplier counterparts to design the solution. At
the Team Level, Agile Teams and the Supplier's
engineers communicate and work together to
deliver the solution. Suppliers and Agile
Release Trains (ARTs) should share interfaces,
tests, and simulators, which should be
documented in the Solution Intent for reference.
8.5: Control of production and service provision:
8.5.3: Property belonging to customers or
external providers
SP2.2Ensure that the supplier agreement is satisfied before accepting
the acquired product.
8.1: Operational planning and control: The
organization shall ensure that outsourced
processes are controlled.
The Supplier, whether using Lean-Agile or
traditional development practices, must
participate in the System Demo and the Solution
Demo (even if they only have documents and
not working systems). In the Supplier's Demos,
the organization should be present to provide
feedback on the working systems being
demonstrated.
8.4: Control of externally provided processes,
products and services: 8.4.2: Type and extent of
control: c) take into consideration: 1) the
potential impact of the externally provided
processes, products and services on the
organization's ability to consistently meet
customer and applicable statutory and
regulatory requirements; d) determine the
verification, or other activities, necessary to
ensure that the externally provided processes,
products and services meet requirements.
Appraisal Considerations:
- The direct artifacts listed here (e.g., typical work products or services) are
commonly specified in supplier agreements, but the presence or absence of some
of these may vary according to the terms of the specific supplier agreement
- See model (SubP3, 4, 5) for typical content and emphasis of technical and
management reviews, which can be formal or informal, and may be held on an
event-driven and periodic basis, as necessary.
Artifact Example:
- No single work product here; all products specified in the supplier agreement
must be considered in assessing this practice
- Supplier progress reports and performance measures
- Supplier review materials and reports
- Documentation of work product and document deliveries
- Action items tracked to closure
- Audits, corrective action requests, and plans to improve supplier performance
- Supporting evidence of supplier technical and management reviews (agenda,
minutes, etc.)
Appraisal Considerations:
- Ensure the acceptance of products or services includes satisfaction of both
technical and non-technical commitments (see model for examples)
- Note that acceptance does not necessarily require testing to ensure satisfaction
of the supplier agreement; other mechanisms may be suitable, such as
inspections, reviews, audits, etc. However, it would be reasonable to expect that
the acceptance results are documented
- Refer to the Verification PA for additional information about verifying products.
Artifact Example:
- Acceptance test results
- Acceptance test procedures
- Discrepancy reports or corrective action plans
- Configuration audit results· Traceability reports indicating coverage of
requirements for the acquired product by acceptance test procedures
- Verification of functional performance, configuration, and adherence to defined
requirements and commitments
- Closure or termination of supplier agreement
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. SAM, Page 3
Page 65
Supplier Agreement Management
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: a) the processes, products
and services to be provided; b) the approval of:
1) products and services; 2) methods,
processes and equipment;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: f) the
performance of external providers;
SP2.3 Ensure the transition of products acquired from the supplier.
8.5: Production and service provision: 8.5.3:
Property belonging to customers or external
providers
Vendors team members may be invited to Sprint
Reviews or even Daily Scrum meetings if they
are integrated with the scrum team. If the vendor
follows Agile development practices, their sprint
schedule shall match the buyer’s sprint
schedule. If the vendor follows traditional
waterfall development practices, the Scrum
Master may need to intervene if the vendor’s
processes or timeline becomes a roadblock for
the scrum team.
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: b) the approval of: 3) the
release of products and services;
For early integration and built-in quality,
Suppliers and Agile Release Trains (ARTs)
should share interfaces, tests, and simulators,
which should be documented in the Solution
Intent for reference.
Appraisal Considerations:
- Ideally, there would be evidence of the transition plan actually being
implemented. Depending on the lifecycle phase of the appraised projects, it may
be difficult to obtain objective evidence of deployment and transition of supplier
products and services. The supplier product may be still be in the acquisition
phase, in which case only transition plans are available. Or, the project may itself
have completed shortly following acceptance and delivery of the acquired product,
and therefore might not even be selected as a sample project for the appraisal.
This might be compensated for by interviews of FAR group members that have
participated in transition
- It may be useful to think of this practice in terms of (1) subcontractors, and (2)
COTS products or services, where this might include delivery and support of
licenses, etc.
Artifact Example:
- Transition plans
- Records reflecting implementation of transition plans
- Training reports
- Support and maintenance reports
- CM reports indicating control, auditing, and maintenance of acquired products
- Records indicating integration of the acquired product or services into the project
- Vendor maintenance agreements
Appraisal Considerations:
- Ensure the acceptance of products or services includes satisfaction of both
technical and non-technical commitments (see model for examples)
- Note that acceptance does not necessarily require testing to ensure satisfaction
of the supplier agreement; other mechanisms may be suitable, such as
inspections, reviews, audits, etc. However, it would be reasonable to expect that
the acceptance results are documented
- Refer to the Verification PA for additional information about verifying products.
Artifact Example:
- Acceptance test results
- Acceptance test procedures
- Discrepancy reports or corrective action plans
- Configuration audit results· Traceability reports indicating coverage of
requirements for the acquired product by acceptance test procedures
- Verification of functional performance, configuration, and adherence to defined
requirements and commitments
- Closure or termination of supplier agreement
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. SAM, Page 4
Page 66
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1
Stakeholder needs, expectations, constraints, and
interfaces are collected and translated into customer
requirements.
SP1.1Elicit stakeholder needs, expectations, constraints, and interfaces
for all phases of the product lifecycle.
4.2: Understanding the needs and expectations
of interested parties
The Product Vision Statement articulates the
goals for the project and must be understood by
the project stakeholders, development team,
and the Scrum Master.
All team members must understand the Solution
Vision, and each level of SAFe® develops their
own Vision of how they will help meet higher-
level objectives.
5.1: Leadership and commitment: 5.1.2:
Customer focus: a) customer and applicable
statutory and regulatory requirements are
determined, understood and consistently met;
The Product Roadmap / Product Backlog is a
living document to which requirements can be
added or changed.
The Roadmap is developed and updated by
Solution and Product Management as the Vision
and delivery strategy evolve.
5.3: Organizational roles, responsibilities, and
authorities: d) ensuring the promotion of
customer focus throughout the organization;
The Sprint Review meeting solicits comments
and feedback from stakeholders on the product
created during the sprint.
The Team Demo and System Demo meeting
solicits comments and feedback from
stakeholders on the product created during the
Iteration/Program Increment.
8.1: Operational planning and control: a)
determining the requirements for the products
and services;
8.2: Requirements for products and services:
8.2.2: Determining the requirements for
products and services: a) the requirements for
the products and services are defined, including:
1) any applicable statutory and regulatory
requirements; 2) those considered necessary by
the organization;
8.5: Production and service provision: 8.5.1:
Control of production and service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
SP1.2Transform stakeholder needs, expectations, constraints and
interfaces into prioritized customer requirements.
4.2: Understanding the needs and expectations
of interested parties
User Stories are created based on identified
stakeholders, including users (who are captured
as personas in the user stories).
5.1: Leadership and commitment: 5.1.2:
Customer focus: a) customer and applicable
statutory and regulatory requirements are
determined, understood and consistently met;
The Product Roadmap / Product Backlog
identifies and groups requirements for the
product and defines high-level estimates for
effort, priority, and time frames.
The SAFe® Roadmap consists of the upcoming
planned and committed Program Increment
(Pis) and the next planned Pis, with upcoming
Milestones indicated.
5.3: Organizational roles, resonsibilities, and
authorities: d) ensuring the promotion of
customer focus throughout the organization;
The Portfolio Kanban captures "big ideas"
derived from the organization's Strategic
Themes, new business opportunities, potential
operational or cost efficiencies, or solutions to
problems hindering the organization. Key
stakeholders participate in capturing, analyzing,
approving, and releasing Epics into
implementation.
8.1: Operational planning and control: a)
determining the requirements for the products
and services;
Appraisal Considerations:
- Refer to the definition of “Test procedure” in the model to help derive the
meaning of “Test case” as used in this SP.
Artifact Examples:
- Customer Requirements
- Requirements for verification process
- Requirements for validation process
Appraisal Considerations:
- In the staged representation, this specific practice takes the place of specific
practice: SP 1.1-1 Collect Stakeholder Needs.
- Refer to model for distinction of “elicit” vs. “identify and collect” requirements.
Artifact Examples:
- Artifacts indicating stakeholder needs, expectations, and constraints (implicit and
explicit)
- Results of requirements collection methods (e.g., Interviews, prototypes,
requirements analyses, market surveys, use cases., product domain analysis)
- Evidence of customer interaction
- Results of requirements reviews to remove conflicts
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 1
Page 67
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.2: Requirements for products and services:
8.2.2: Determining the requirements for
products and services: a) the requirements for
the products and services are defined, including:
1) any applicable statutory and regulatory
requirements; 2) those considered necessary by
the organization;
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: c) include or reference monitoring and
measuring requirements, as appropriate, and
acceptance criteria;
SG2Customer requirements are refined and elaborated to
develop product and product component requirements.
SP2.1Establish and maintain product and product component
requirements, which are based on the customer requirements.
5.1: Leadership and commitment: 5.1.2:
Customer focus: a) customer and applicable
statutory and regulatory requirements are
determined, understood and consistently met;
The Product Roadmap / Product Backlog
identifies and groups the product requirements
and prioritizes and creates high-level time
frames.
The SAFe® Roadmap consists of the upcoming
planned and committed Program Increment
(Pis) and the next planned Pis, with upcoming
Milestones indicated.
5.2: Policy: 5.2.1: Establishing the quality policy:
c) includes a commitment to satisfy applicable
requirements;
User Stories are created based on identified
Themes and Features in the Product Roadmap /
Product Backlog.
Epics are broken down and elaborated into
Capabilities, Features, and Stories as they flow
down through Kanban systems in the Portfolio,
Value Stream, Program, and Team levels,
respectively.
8.1: Operational planning and control: a)
determining the requirements for the products
and services;
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: a) meet the input requirements
SP2.2 Allocate the requirements for each product component.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process stages, including applicable
design and development reviews;
The Release Plan (when applicable) organizes
user stories from the Product Backlog into a
release schedule for a specific set of features.
The Sprint Backlog contains the user stories
associated with the current sprint to create the
specific group of product capabilities defined in
the Sprint Plan (and Release Plan).
Requirements may be broken down
(decomposed) into Themes, Features, Epic
User Stories, User Stories, or Tasks, which
describe the requirements in terms of its value
to the end user.
Functional system behavior is described and
broken down, from Epics to Capabilities,
Features, and then Stories at the Portfolio,
Value Stream, Program, and Team levels,
respectively.
Appraisal Considerations:
- None
Artifact Examples:
- Requirement allocation sheets
- Provisional requirement allocations
- Derived requirements
- Relationships between derived requirements
- Specifications
- Design constraints
- Indication of allocated requirements traceability
- Include allocation of product performance, design constraints, and fit, form, and
function
Appraisal Considerations:
- Refer to the definition of “Test procedure” in the model to help derive the
meaning of “Test case” as used in this SP.
Artifact Examples:
- Customer Requirements
- Requirements for verification process
- Requirements for validation process
Appraisal Considerations:
- None
Artifact Examples:
- Derived requirements
- Product requirements
- Product component requirements
- Results of methods (e.g., House of quality) used to translate customer needs into
technical parameters
- Requirements traceability matrix
- Revision histories of requirements
- Analysis of cost performance tradeoffs of requirements and of lifecycle phases
considering business objectives
- Performance modeling results
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 2
Page 68
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Design Constraints are restrictions or standards
on the design or development of a system and
are a part of the Nonfunctional Requirements
(NFRs) which are captured as User Stories or
as Backlog Constraints.
Nonfunctional Requirements describe system
attributes such as security, reliability,
maintainability, and scalability, as well as design
constraints. They are used in SAFe® as
"backlog constraints" and incorporated into the
Definition of Done.
The Value Stream/Program Planning Board
captures and tracks the dependencies between
pieces of functionality as well as Enablers.
SP2.3 Identify interface requirements.
Appraisal Considerations:
- None
Artifact Examples:
- Interface requirements
- Architecture documents
- Integration test plans
- Interface requirements
- Architecture documents
- Integration test plans
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process stages, including applicable
design and development reviews;
Continuous Integration is the ScrumXP practice
of working from the latest version of code and
integrating code components as often as
possible as soon as they are ready.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build
requires members of Agile Teams to integrate
their code at least once per Iteration (preferably
more often), and Teams within ARTs to
integrate their code at least partially several
times within a Program Increment (PI).
SG3 The requirements are analyzed and validated.
SP3.1Establish and maintain operational concepts and associated
scenarios.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:c) requirements specified
by the organization;
The Product Vision Statement articulates the
goals for the project and must be understood by
the project stakeholders, development team,
and the Scrum Master.
All team members must understand the Solution
Vision, and each level of SAFe® develops their
own Vision of how they will help meet higher-
level objectives.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:d) statutory and regulatory
requiremens applicable to the products and
services;
Solution Intent is a knowledge repository which
stores, manages, and communicates what
system builders are building and how they are
going to build it. Solution Intent has both Fixed
and Variable elements which allows the Solution
Intent to be adaptable to change yet defined
enough to be able to create the Solution.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:e) contract or order
requirements differing from those previously
expressed.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:The customer's
requirements shall be confirmed by the
organization before acceptance, when the
customer does not provide a documented
statement of their requirements.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: a) the results to be achieved are
defined;
Appraisal Considerations:
- None
Artifact Examples:
- Operational concept
- Product installation, maintenance and support concepts
- Disposal concepts
- Scenarios (e.g., Use cases, Timeline scenarios
- Revision histories
- New requirements
Appraisal Considerations:
- None
Artifact Examples:
- Requirement allocation sheets
- Provisional requirement allocations
- Derived requirements
- Relationships between derived requirements
- Specifications
- Design constraints
- Indication of allocated requirements traceability
- Include allocation of product performance, design constraints, and fit, form, and
function
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 3
Page 69
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.5: Production and service provision: 8.5.1:
Control of production andd service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
SP3.2Establish and maintain a definition of required functionality and
quality attributes.
6.2: Quality objectives and planning to achieve
them: 6.2.1: c) take into account applicable
requirements; d) be relevant to conformity of
products and services and to enhancement of
customer satisfaction;
The Product Roadmap / Product Backlog
identifies and groups requirements for the
product.
The SAFe® Roadmap consists of a the
upcoming planned and committed Program
Increment (Pis) and the next planned Pis, with
upcoming Milestones indicated.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:c) requirements specified
by the organization;
The Program and Value Stream Backlog
contains all of the upcoming work that affects
the Solution, including Features/Capabilities and
Enablers.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:d) statutory and regulatory
requiremens applicable to the products and
services;
The Team Backlog contains all of the things that
the team needs to do to advance their part of
the work.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:e) contract or order
requirements differing from those previously
expressed.
User Stories are created based on identified
Themes and Features in the Product Roadmap /
Product Backlog.
Functional system behavior is described and
broken down, from Epics to Capabilities,
Features, and then Stories at the Portfolio,
Value Stream, Program, and Team levels,
respectively.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:The customer's
requirements shall be confirmed by the
organization before acceptance, when the
customer does not provide a documented
statement of their requirements.
Design Constraints are restrictions or standards
on the design or development of a system and
are a part of the Nonfunctional Requirements
(NFRs) which are captured as User Stories or
as Backlog Constraints.
Nonfunctional Requirements describe system
attributes such as security, reliability,
maintainability, and scalability, as well as design
constraints. They are used in SAFe® as
"backlog constraints" and incorporated into the
Definition of Done.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
a) functional and performance requirements;
The Value Stream/Program Planning Board
captures and tracks the dependencies between
pieces of functionality as well as Enablers.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: a) the results to be achieved are
defined;
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: The organization shall retain
documented information on design and
development outputs.
Appraisal Considerations:
- None
Artifact Examples:
- Operational concept
- Product installation, maintenance and support concepts
- Disposal concepts
- Scenarios (e.g., Use cases, Timeline scenarios
- Revision histories
- New requirements
Appraisal Considerations:
- See RD SP 2.1 for product component requirements.
Artifact Examples:
- Functional architecture
- Functional requirements
- Activity diagrams and use cases
- Object oriented analysis with services identified
- Results of analysis of requirements for subfunctions that identify logical or
functional partitions of requirements
- Traceability of functional requirements that relate to product operation
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 4
Page 70
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.5: Production and service provision: 8.5.1:
Control of production andd service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
8.5: Production and service provision: 8.5.4:
Preservation
SP3.3Analyze requirements to ensure that they are necessary and
sufficient.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:c) requirements specified
by the organization;
The Product Owner is responsible for creating
and maintaining the Product Backlog by adding
and prioritizing User Stories.
The Product Owner is responsible for creating
and maintaining the Team Backlog by adding
and prioritizing Stories.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:d) statutory and regulatory
requiremens applicable to the products and
services;
The Review and Analysis phases of the
Portfolio, Value Stream, and Program Kanbans
evaluate and elaborate ideas captured from the
Funnel phase.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:e) contract or order
requirements differing from those previously
expressed.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:The customer's
requirements shall be confirmed by the
organization before acceptance, when the
customer does not provide a documented
statement of their requirements.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
a) functional and performance requirements;
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
c) statutory and regulatory requirements;
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
e) potential consequences of failure due to the
nature of the products and services.
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers
Appraisal Considerations:
- None
Artifact Examples:
- Requirements defects reports
- Key requirements
- Proposed requirements changes to resolve defects
- Technical performance measures
Appraisal Considerations:
- See RD SP 2.1 for product component requirements.
Artifact Examples:
- Functional architecture
- Functional requirements
- Activity diagrams and use cases
- Object oriented analysis with services identified
- Results of analysis of requirements for subfunctions that identify logical or
functional partitions of requirements
- Traceability of functional requirements that relate to product operation
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 5
Page 71
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.5: Production and service provision: 8.5.1:
Control of production andd service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
SP3.4Analyze requirements to balance stakeholder needs and
constraints.
4.2: Understanding the needs and expectations
of interested parties
The Review and Analysis phases of the
Portfolio, Value Stream, and Program Kanbans
evaluate and elaborate ideas captured from the
Funnel phase.
5.1: Leadership and commitment: 5.1.2:
Customer focus: a) customer and applicable
statutory and regulatory requirements are
determined, understood and consistently met;
During the Management Review and Problem-
Solving phase of PI Planning, management
agrees to planning adjustments based on
scope, resource, and dependency constraints.
8.2: Requirements for products and services:
8.2.2: Determining the requirements for
products and services: b) the organization can
meet the claims for the products and services it
offers.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:c) requirements specified
by the organization;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:d) statutory and regulatory
requiremens applicable to the products and
services;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:e) contract or order
requirements differing from those previously
expressed.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:The customer's
requirements shall be confirmed by the
organization before acceptance, when the
customer does not provide a documented
statement of their requirements.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
d) standards or codes of practice that the
organization has committed to implement;
Appraisal Considerations:
- None
Artifact Examples:
- Assessment of risks related to requirements
- Results of requirements analysis indicating impact on cost and schedule
- Risk mitigation plan
- Project Management plan
Appraisal Considerations:
- None
Artifact Examples:
- Requirements defects reports
- Key requirements
- Proposed requirements changes to resolve defects
- Technical performance measures
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 6
Page 72
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.5: Production and service provision: 8.5.1:
Control of production andd service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.2: Customer satisfaction
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation: b) the
degree of customer satisfaction;
SP3.5Validate requirements to ensure the resulting product will perform
as intended in the end user's environment.
5.1: Leadership and commitment: 5.1.2:
Customer focus: a) customer and applicable
statutory and regulatory requirements are
determined, understood and consistently met;
The Product Owner Review verifies that
completed user stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
6.2: Quality objectives and planning to achieve
them: 6.2.1: d) be relevant to conformity of
products and services and to enhancement of
customer satisfaction;
A card-based User Story system typically has
the requirements on the front side of the card,
and the verification steps to confirm the work
product meets the requirement on the back side
of the card.
The SAFe® requirements model requires
success criteria and/or acceptance criteria for
the resulting work products of Epics,
Capabilities, Features, Stories, and
Nonfunctional Requirements (NFRs).
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:c) requirements specified
by the organization;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:d) statutory and regulatory
requiremens applicable to the products and
services;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:e) contract or order
requirements differing from those previously
expressed.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:The customer's
requirements shall be confirmed by the
organization before acceptance, when the
customer does not provide a documented
statement of their requirements.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: b) reviews are conducted to evaluate
the ability of the results of design and
development to meet requirements;
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: b) are adequate for the subsequent
processes for the provision of products and
services;
Appraisal Considerations:
- None
Artifact Examples:
- Assessment of risks related to requirements
- Results of requirements analysis indicating impact on cost and schedule
- Risk mitigation plan
- Project Management plan
Appraisal Considerations:
- In the staged representation, this specific practice takes the place of specific
practice: SP 3.5 Validate Requirements.
- See Risk Management PA. This SP activity should be integrated with the risk
management activities.
Artifact Examples:
- Record of analysis methods and results
- Validation methodology
- Requirements traceability matrix
- Requirements specification§ Requirements changes
- Results of techniques to demonstrate requirements functionality (e.g.,
prototypes, simulations, analyses, scenarios, and story boards)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 7
Page 73
Requirements Development
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: d) specify the characteristics of the
products and services that are essential for their
intended purpose and their SAFe® and proper
provision.
8.4: Control of externally provided processes,
products and services: 8.4.2: Type and extent of
control: d) determine the verification, or other
activities, necessary to ensure that the externally
provided processes, products and services meet
requirements.
8.5: Production and service provision: 8.5.1:
Control of production andd service provision: a)
the availability of documented information that
defines: 1) the characteristics of the products to
be produced, the services to be provided, or the
activities to be performed; 2) the results to be
achieved;
8.5:Production and service provision: 8.5.5: Post-
delivery activities
Appraisal Considerations:
- In the staged representation, this specific practice takes the place of specific
practice: SP 3.5 Validate Requirements.
- See Risk Management PA. This SP activity should be integrated with the risk
management activities.
Artifact Examples:
- Record of analysis methods and results
- Validation methodology
- Requirements traceability matrix
- Requirements specification§ Requirements changes
- Results of techniques to demonstrate requirements functionality (e.g.,
prototypes, simulations, analyses, scenarios, and story boards)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 8
Page 74
Technical Solution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1Product or product component solutions are selected
from alternative solutions.SP1.1 Develop alternative solutions and selection criteria.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities;
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
b) information derived from previous similar
design and development activities;
Design, implementation, and solution
alternatives are added into the Funnel phase of
the Portfolio Kanban, Value Stream Kanban,
and Program Kanban as Epics, Capabilities, or
Features, respectively.
Using Set-Based Design in accordance with
SAFe® Principle #3 “Assume variability,
preserve options”, alternatives can be evaluated
using their economic trade-offs by plotting them
on a spectrum with a different weight for each
alternative, or plotting them with two different
factors (such as cost and performance) to make
a trade-off curve.
Using Model-Based Systems Engineering
(MBSE) in accordance with SAFe® practices,
modeling, prototyping, and simulations can be
used to eliminate some alternatives and validate
others.
SP1.2Select the product component solutions based on selection
criteria.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities;
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. The Scrum Master
first checks that the product/service is not
available internally before working with the
development team and Product Owner to
procure the product/service. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
Design, implementation, and solution
alternatives are explored during the Analysis
phase of the Portfolio Kanban, Value Stream
Kanban, and Program Kanban.
The highest-priority epics/capabilities/features
that are sufficiently elaborated during the
Analysis phase of the Portfolio, Value Stream,
and Program Kanban and approved are moved
to their respective Backlogs and are moved into
Implementation phase when ready at relevant PI
Planning boundaries.
Appraisal Considerations:
- None
Artifact Examples:
- Alternative solutions
- Selection criteria
- Evaluations of new technologies
- Checklists for alternative solution screening criteria
- Evaluation of solutions and technologies (new or legacy)
- Requirements allocation for each alternative and their associated cost
- Design issues
- A process or processes for identifying solution alternatives, selection criteria,
and design issues
- COTS evaluations
Appraisal Considerations:
- Product component solutions should be selected using the criteria established in
SP1.1 (or SP1.1, as applicable)
- Look for documented decisions and rationale, according to the selection criteria
- Refer to the RD PA for information on establishing allocated requirements and
interface requirements
- Refer to the DAR PA for more information about structured decision making
- “The descriptions of the solutions and rationale for selection are documented in
an initial technical data package. The technical data package evolves throughout
development….”
- Rationale for selection decisions should be maintained to support downstream
decision making
- See CMMI glossary for a definition of “technical data package.”
Artifact Examples:
- Product component selection decisions and rationale
- Documented relationships between requirements and product components
- Initial product component technical data package
- Alternative solutions under consideration and selection criteria (see SP1.1)
- Operating concepts, modes, and states (see SP.1.2)
- Technical memos
- Requirements allocated to product components
- Resolution of issues for selection of best alternative solution using the functional
requirements as a parameter
- Documentation of selected solutions using the allocated requirements and
selected product components
- Processes and procedures for selection of product component solutions
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. TS, Page 1
Page 75
Technical Solution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Using Set-Based Design in accordance with
SAFe® Principle #3 “Assume variability,
preserve options”, alternatives can be evaluated
using their economic trade-offs by plotting them
on a spectrum with a different weight for each
alternative, or plotting them with two different
factors (such as cost and performance) to make
a trade-off curve.
Using Model-Based Systems Engineering
(MBSE) in accordance with SAFe® practices,
modeling, prototyping, and simulations can be
used to eliminate some alternatives and validate
others.
SG2 Product or product component designs are developed.
SP2.1 Develop a design for the product or product component.
8.3: Design and development of products and
services: 8.3.1: General
Design Constraints are restrictions or standards
on the design or development of a system and
are a part of the Nonfunctional Requirements
(NFRs) which are captured as User Stories or
as Backlog Constraints.
Nonfunctional Requirements describe system
attributes such as security, reliability,
maintainability, and scalability, as well as design
constraints. They are used in SAFe® as
"backlog constraints" and incorporated into the
Definition of Done.
Elaboration is performed during a sprint to
determine the details of a product feature, and is
performed by the Product Owner and the
development team.
The highest-priority epics/capabilities/features
that are sufficiently elaborated during the
Analysis phase of the Portfolio, Value Stream,
and Program Kanban and approved are moved
to their respective Backlogs and are moved into
Implementation phase when ready at relevant PI
Planning boundaries.
Solution Intent is a knowledge repository which
stores, manages, and communicates what
system builders are building and how they are
going to build it. Solution Intent has both Fixed
and Variable elements which allows the Solution
Intent to be adaptable to change yet defined
enough to be able to create the Solution.
SP2.2 Establish and maintain a technical data package.
8.3: Design and development of products and
services: 8.3.1: General
Documentation is (usually) a part of the agreed-
upon Definition of Done, the criteria a
requirement must meet if it is to be considered
completed.
A scaled Definition of Done may require the
Solution Increment to have updated
documentation, and the Release to have
completed release documentation.
Appraisal Considerations:
- See model (informative material and glossary) for description of a technical data
package and typical contents, as applicable to the product component. Note the
distinction in completeness between contents of the technical data package that
might be provided at CL1 (SP2.2) and CL3 (SP2.2)
- This SP, and the PA in general, should be considered from the aspects of
deployment at multiple levels of the product or component design and
implementation
- “A complete design description is contained is documented in a technical data
package that includes a full range of features and parameters including form, fit,
function, interface, manufacturing process characteristics, and other parameters.”
- Look for documented relationships among the different product requirements and
their sub components
- Look for the levels of design and appropriate level of documentation for each
design level
Artifact Examples:
- Complete technical data package
- Description and rationale for the design solution decisions chosen for
implementation
- Drawings, lists, specifications, standards, performance requirements, QA
provisions, packaging details associated with the component
- Documentation or materials from design reviews at which the technical data
package or its components were reviewed
- Product component requirements specifications and related processes
- Interface requirements
- Revisions to work products, standards and procedures reflecting iteration in the
product implementation or corrective action
- Functional descriptions and usage scenarios (e.g., states, modes, support,
training, manufacturing, disposal, verifications)
- Verification criteria
- Multiple views of the design hierarchy (customer view, functional view, data view,
etc.)
Appraisal Considerations:
- Product component solutions should be selected using the criteria established in
SP1.1 (or SP1.1, as applicable)
- Look for documented decisions and rationale, according to the selection criteria
- Refer to the RD PA for information on establishing allocated requirements and
interface requirements
- Refer to the DAR PA for more information about structured decision making
- “The descriptions of the solutions and rationale for selection are documented in
an initial technical data package. The technical data package evolves throughout
development….”
- Rationale for selection decisions should be maintained to support downstream
decision making
- See CMMI glossary for a definition of “technical data package.”
Artifact Examples:
- Product component selection decisions and rationale
- Documented relationships between requirements and product components
- Initial product component technical data package
- Alternative solutions under consideration and selection criteria (see SP1.1)
- Operating concepts, modes, and states (see SP.1.2)
- Technical memos
- Requirements allocated to product components
- Resolution of issues for selection of best alternative solution using the functional
requirements as a parameter
- Documentation of selected solutions using the allocated requirements and
selected product components
- Processes and procedures for selection of product component solutions
Appraisal Considerations:
- “Effective design methods can embody a wide range of activities, tools, and
descriptive techniques.”
- The term “effective” is subjective and difficult to assess consistently; the team
must be careful not to fall into judging “goodness of the process”. Rather, the team
should look for thorough but reasonable design standards, tools, and processes
that provide sufficient guidance for effective and repeatable project
implementations, which may vary according to product characteristics and
constraints.
- Implementation of this practice should include not only the standards for
establishing and documenting a design, but also evidence that these standards
are followed (e.g., completed review documentation or checklists)
- Look for sufficient detail in product or product component designs to support life-
cycle content (e.g., implementation, modification, reprocurement, maintenance,
sustainment, installation)
- See model for examples of software design methods (prototyping, structural
models, OOD, patterns, etc.), standards (user interface, safety, production, etc.),
design attributes and criteria (modularity, maintainability, performance, etc.).
- The design methods used may vary for different portions of the product
component design.
- Criteria are maintained through a process against which the effectiveness are
measured.
Artifact Examples:
- Organizational and project design standards, activities, and tools
- Criteria for design methods
- Criteria for selection of the design method
- Design tools
- Design process/activities
- Guidance for appropriate selection from the approved set of supported design
methods
- Set of approved design tools, with guidance on their role and usage in the design
process
- Criteria and completed evaluations (e.g. checklists) of design effectiveness
standards
- Documented design criteria attributes (modularity, clarity, reliability , accuracy)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. TS, Page 2
Page 76
Technical Solution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Solution Intent is a knowledge repository which
stores, manages, and communicates what
system builders are building and how they are
going to build it. Solution Intent has both Fixed
and Variable elements which allows the Solution
Intent to be adaptable to change yet defined
enough to be able to create the Solution.
Using the SAFe® practice of Model-Based
Systems Engineering (MBSE), documents
should be generated from information in system
models. Document templates should be defined
early as they will influence many of the model
standards.
SP2.3 Design product component interfaces using established criteria.
8.3: Design and development of products and
services: 8.3.1: General
Development is performed during a sprint based
on the user stories in the sprint backlog to
create shippable functionality.
Design Constraints are restrictions or standards
on the design or development of a system and
are a part of the Nonfunctional Requirements
(NFRs) which are captured as User Stories or
as Backlog Constraints.
Nonfunctional Requirements describe system
attributes such as security, reliability,
maintainability, and scalability, as well as design
constraints. They are used in SAFe® as
"backlog constraints" and incorporated into the
Definition of Done.
Elaboration is performed during a sprint to
determine the details of a product feature, and is
performed by the Product Owner and the
development team.
The highest-priority epics/capabilities/features
that are sufficiently elaborated during the
Analysis phase of the Portfolio, Value Stream,
and Program Kanban and approved are moved
to their respective Backlogs and are moved into
Implementation phase when ready at relevant PI
Planning boundaries.
Solution Intent is a knowledge repository which
stores, manages, and communicates what
system builders are building and how they are
going to build it. Solution Intent has both Fixed
and Variable elements which allows the Solution
Intent to be adaptable to change yet defined
enough to be able to create the Solution.
Appraisal Considerations:
- See model (informative material and glossary) for description of a technical data
package and typical contents, as applicable to the product component. Note the
distinction in completeness between contents of the technical data package that
might be provided at CL1 (SP2.2) and CL3 (SP2.2)
- This SP, and the PA in general, should be considered from the aspects of
deployment at multiple levels of the product or component design and
implementation
- “A complete design description is contained is documented in a technical data
package that includes a full range of features and parameters including form, fit,
function, interface, manufacturing process characteristics, and other parameters.”
- Look for documented relationships among the different product requirements and
their sub components
- Look for the levels of design and appropriate level of documentation for each
design level
Artifact Examples:
- Complete technical data package
- Description and rationale for the design solution decisions chosen for
implementation
- Drawings, lists, specifications, standards, performance requirements, QA
provisions, packaging details associated with the component
- Documentation or materials from design reviews at which the technical data
package or its components were reviewed
- Product component requirements specifications and related processes
- Interface requirements
- Revisions to work products, standards and procedures reflecting iteration in the
product implementation or corrective action
- Functional descriptions and usage scenarios (e.g., states, modes, support,
training, manufacturing, disposal, verifications)
- Verification criteria
- Multiple views of the design hierarchy (customer view, functional view, data view,
etc.)
Appraisal Considerations:
- See model (informative material and glossary) for description of a technical data
package and typical contents, as applicable to the product component. Note the
distinction in completeness between contents of the technical data package that
might be provided at CL1 (SP2.2) and CL3 (SP2.2)
- This SP, and the PA in general, should be considered from the aspects of
deployment at multiple levels of the product or component design and
implementation
- “A complete design description is contained is documented in a technical data
package that includes a full range of features and parameters including form, fit,
function, interface, manufacturing process characteristics, and other parameters.”
- Look for documented relationships among the different product requirements and
their sub components
- Look for the levels of design and appropriate level of documentation for each
design level
Artifact Examples:
- Complete technical data package
- Description and rationale for the design solution decisions chosen for
implementation
- Drawings, lists, specifications, standards, performance requirements, QA
provisions, packaging details associated with the component
- Documentation or materials from design reviews at which the technical data
package or its components were reviewed
- Product component requirements specifications and related processes
- Interface requirements
- Revisions to work products, standards and procedures reflecting iteration in the
product implementation or corrective action
- Functional descriptions and usage scenarios (e.g., states, modes, support,
training, manufacturing, disposal, verifications)
- Verification criteria
- Multiple views of the design hierarchy (customer view, functional view, data view,
etc.)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. TS, Page 3
Page 77
Technical Solution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SP2.4Evaluate whether the product components should be developed,
purchased, or reused based on established criteria.
7.1: Resources: 7.1.1: General.
COTS (commercial off-the-shelf) solutions may
be determined as needed by the development
team at any stage of scrum. The Scrum Master
first checks that the product/service is not
available internally before working with the
development team and Product Owner to
procure the product/service. Records of
evaluating and comparing COTS products and
services may be generated and purchases are
reflected in the project budget.
8.3: Design and development of products and
services: 8.3.1: General
SG3Product components, and associated support
documentation, are implemented from their designs.SP3.1 Implement the designs of the product components.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: h) the requirements for subsequent
provision of products and services;
Development is performed during a sprint based
on the user stories in the sprint backlog to
create shippable functionality.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: j) the documented information needed
to demonstrate that design and development
requirements have been met;
Requirements may be broken down
(decomposed) into Themes, Features, Epic
User Stories, User Stories, or Tasks, which
describe the requirements in terms of its value
to the end user.
Functional system behavior is described and
broken down, from Epics to Capabilities,
Features, and then Stories at the Portfolio,
Value Stream, Program, and Team levels,
respectively.
Solution Intent is a knowledge repository which
stores, manages, and communicates what
system builders are building and how they are
going to build it. Solution Intent has both Fixed
and Variable elements which allows the Solution
Intent to be adaptable to change yet defined
enough to be able to create the Solution.
SP3.2 Develop and maintain the end-use documentation.
Appraisal Considerations:
- “Methods to implement the product components are documented, either directly
or by reference, in the project’s defined process.”
- See model for examples of criteria for evaluation of product component
standards (e.g., coding standards and conventions, modularity, standard parts
lists, drawing requirements).
- Refer to the Verification PA for more information on peer reviews performed on
product components.
- Look for evidence of satisfying unit test criteria (e.g., test coverage (statement
coverage, branch coverage, path coverage, etc.), bounds).
- Ensure peer reviews are performed on selected product components.
Artifact Examples:
- Implemented design
- Product component implementation and support data (e.g., source code,
documented data and services, fabricated parts, deployed manufacturing
processes, facilities, materials).
- Product component construction methods (e.g. coding, fabrication).
- Standards, criteria, and checklists for constructed product components.
- Results of peer reviews, inspections, or verifications performed on constructed
components.
- Unit test plans, procedures, results, and acceptance criteria.
- Configuration and change control data for revision to product components.
Appraisal Considerations:
- Refer to the DAR PA for additional information on structured decision making.
- Refer to the SAM PA for additional information on make-buy analyses and
acquisition of product components that will be purchased.
- Look for thorough analysis and plans for maintenance and support of
components across the product lifecycle.
Artifact Examples:
- Criteria for design and component reuse
- Make or buy analyses including the factors that were taken into consideration
- Functions the products or services will provide
- Available project resources and skills
- Costs of acquiring versus developing internally
- Strategic business alliances
- Market research of available products
- Functionality and quality of available products
- Skills and capabilities of potential suppliers
- Product availability
- Guidance for choosing COTS components
- Supplier agreements.
- Reuse component libraries, guidance, and criteria for reuse of non-
developmental items (NDI).
- Evaluation criteria, rationale, and reports for make-buy analyses and product
component selection.
- Plans for maintenance, support, and transition of COTS/NDI components.
- Product acceptance criteria.
- Product operational, maintenance and support concepts
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. TS, Page 4
Page 78
Technical Solution
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: j) the documented information needed
to demonstrate that design and development
requirements have been met;
User Documentation is created during the
Release Sprint.
A scaled Definition of Done may require the
Solution Increment to have updated
documentation, and the Release to have
completed release documentation.
8.5: Control of production and service provision:
8.5.4: Preservation
Appraisal Considerations:
- “Documentation methods are documented, either directly or by reference, in the
project’s defined process.”
- Look for revision of affected documentation upon changes to requirements,
design, implementation.
Artifact Examples:
- End-user training materials
- User’s manual
- Operator’s manual
- Maintenance manual
- Documentation for installation, operation, use, maintenance and support of
product components.
- Revision history and maintenance of product documentation.
- Installation Manual
- On-line help
- Documentation processes, standards, criteria, and checklists.
- Help desk support.
- Artifacts related to peer review of applicable documentation.
- Site installation, training, and maintenance records.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. TS, Page 5
Page 79
Product Integration
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1 Preparation for product integration is conducted.SP1.1 Establish and maintain a product integration strategy.
8.1: Operational planning and control: b)
establishing criteria for: 1) the processes;
Continuous Integration is the ScrumXP practice
of working from the latest version of code and
integrating code components as often as
possible as soon as they are ready.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build
requires members of Agile Teams to integrate
their code at least once per Iteration (preferably
more often), and Teams within ARTs to
integrate their code at least partially several
times within a Program Increment (PI).
For early integration and built-in quality,
Suppliers and Agile Release Trains (ARTs)
should share interfaces, tests, and simulators,
which should be documented in the Solution
Intent for reference.
SP1.2Establish and maintain the environment needed to support the
integration of the product components.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: d)
the use of suitable infrastructure and
environment for the operation of processes;
Continuous Integration is a performed as often
as possible as a part of the workday during a
sprint.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build
requires members of Agile Teams to integrate
their code at least once per Iteration (preferably
more often), and Teams within ARTs to
integrate their code at least partially several
times within a Program Increment (PI).
For early integration and built-in quality,
Suppliers and Agile Release Trains (ARTs)
should share interfaces, tests, and simulators,
which should be documented in the Solution
Intent for reference.
SP1.3Establish and maintain procedures and criteria for integration of
the product components.
8.1: Operational planning and control: b)
establishing criteria for: 1) the processes
A card-based User Story system typically has
the requirements on the front side of the card,
and the verification steps to confirm the work
product meets the requirement on the back side
of the card.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build
requires members of Agile Teams to integrate
their code at least once per Iteration (preferably
more often), and Teams within ARTs to
integrate their code at least partially several
times within a Program Increment (PI).
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process stages, including applicable
design and development reviews;
For early integration and built-in quality,
Suppliers and Agile Release Trains (ARTs)
should share interfaces, tests, and simulators,
which should be documented in the Solution
Intent for reference.
SG2The product component interfaces, both internal and
external, are compatible.
SP2.1 Review interface descriptions for coverage and completeness.
Appraisal Considerations:
- In general, when considering “planning and strategy” SPs, it may be useful to
think in terms of this being documented in project plans, e.g. product integration
plan, or system integration and test plan. This need not necessarily be a separate
plan, and could be informal, but should be documented.
- Refer to the Technical Solution PA for information about design/development of
product components and defining interfaces
Artifact Examples:
- Product integration sequence
- Product integration plan
- Rationale for selecting or rejecting integration sequences
- List of components to be integrated· Integration schedules and dependencies
- Meetings or presentations at which the plans for product integration are reviewed
Appraisal Considerations:
- It may be useful think in terms of an integration test bed, test harnesses,
simulators, etc., in considering this practice.
- A demonstration of the integration environment might be used as a source of
evidence.
- The product integration plan, or equivalent, should document the planned
integration environment. Resources within the environment may be acquired,
developed, or reused.
Artifact Examples:
- Verified environment for product integration
- Descriptions or configuration of the verified environment for product integration,
revised and maintained throughout the project
- Support documentation for the product integration environment
- Product integration plan
- Product integration test bed (e.g., test equipment, simulators, HW equipment,
recording devices)
Appraisal Considerations:
- See model for several examples on content of integration procedures and criteria
(e.g., incremental builds; expected tests; thresholds; environment and resources;
acceptability).
Artifact Examples:
- Product integration procedures
- Product integration criteria
- Revision history of integration procedures and criteria, maintained throughout the
project
- Criteria and checklists for product-component readiness, integration, and
evaluation
- Criteria and checklists for validation, and delivery of the integrated product
- Product integration inputs, outputs, expected results, and progress criteria·
Incremental build/integration plan and procedures
- Reviews or presentations of integration plans, procedures, and criteria
- Test readiness reviews
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PI, Page 1
Page 80
Product Integration
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Appraisal Considerations:
- “The interfaces should include, in addition to product-component interfaces, all
the interfaces with the product integration environment.”
- For SW: see model for typical contents of interface descriptions (e.g., origination,
destination, stimulus, protocols)
- For SE: see model for typical interface data and categories (e.g., mechanical,
electrical, electromagnetic, man-machine interface)
- Although the interface descriptions may have been generated elsewhere, e.g.,
Technical Solution PA, the intent of this practice is to review the interface
descriptions from an integration and compatibility standpoint
Artifact Examples:
- Reviewed interface descriptions
- Categories of interfaces (e.g., environmental, physical, functional, mechanical)
- List of interfaces per category
- Mapping of the interfaces to the product components and product integration
environment
- Interface specifications, Interface control documents (ICDs), Interface design
documents (IDDs)
- Criteria and checklists for interface reviews
- Result of interface reviews (e.g., peer reviews, quality assurance inspections,
design reviews, interface control working groups, CCBs, action items to resolve
interface issues)
- Interface connection markings
- Traceability matrices between requirements and interfaces
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
Inputs shall be adequate for design and
development purposes, complete and
unambiguous.
A card-based User Story system typically has
the requirements on the front side of the card,
and the verification steps to confirm the work
product meets the requirement on the back side
of the card.
The SAFe® requirements model requires
success criteria and/or acceptance criteria for
the resulting work products of Epics,
Capabilities, Features, Stories, and
Nonfunctional Requirements (NFRs).
SP2.2Manage internal and external interface definitions, designs, and
changes for products and product components.
8.3: Design and development of products and
services: 8.3.3: Design and development inputs:
Conflicting design and development inputs shall
be resolved.
Design Constraints are restrictions or standards
on the design or development of a system and
are a part of the Nonfunctional Requirements
(NFRs) which are captured as User Stories or
as Backlog Constraints.
Nonfunctional Requirements describe system
attributes such as security, reliability,
maintainability, and scalability, as well as design
constraints. They are used in SAFe® as
"backlog constraints" and incorporated into the
Definition of Done.
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: b) are adequate for the subsequent
processes for the provision of products and
services;
Documentation is (usually) a part of the agreed-
upon Definition of Done, the criteria a
requirement must meet if it is to be considered
completed.
A scaled Definition of Done may require the
Solution Increment to have updated
documentation, and the Release to have
completed release documentation.
SG3Verified product components are assembled and the
integrated, verified, and validated product is delivered.
SP3.1
Confirm, prior to assembly, that each product component required
to assemble the product has been properly identified, behaves
according to its description, and that the product component
interfaces comply with the interface descriptions.
Appraisal Considerations:
- The intent of this practice is to ensure that interfaces and revisions to interfaces
are defined, managed, communicated, and controlled.
Artifact Examples:
- List of agreed-to interfaces defined for each pair of product components, when
applicable
- Updated interface description or agreement
- Interface descriptions and relationships among product components
- Interface specifications, Interface control documents (ICDs), Interface design
documents (IDDs)
- Table of relationships between the product components and the external
environment (e.g., main power supply, fastening product, computer bus system)
- Table of relationships between the different product components
- Reports from the interface control working group meetings
- Action items for updating interfaces
- Application Program Interface (API)
- Result of interface reviews (e.g., peer reviews, quality assurance inspections,
design reviews, interface control working groups, CCBs, action items to resolve
interface issues)
- Repository of interface data (e.g. interface data base).
- Change requests for revision to interfaces
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PI, Page 2
Page 81
Product Integration
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: c) verification activities are conducted
to ensure that the design and development
outputs meet the input requirements; d)
validation activities are conducted to ensure that
the resulting products and services meet the
requirements for the specified application or
intended use;
A card-based User Story system typically has
the requirements on the front side of the card,
and the verification steps to confirm the work
product meets the requirement on the back side
of the card.
The SAFe® requirements model requires
success criteria and/or acceptance criteria for
the resulting work products of Epics,
Capabilities, Features, Stories, and
Nonfunctional Requirements (NFRs).
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: a) meet the input requirements; b) are
adequate for the subsequent processes for the
provision of products and services; c) include or
reference monitoring and measuring
requirements, as appropriate, and acceptance
criteria;
The Define-Build-Test lifecycle is used for each
user story in order to complete it.
The Define-Build-Test lifecycle is used for each
Story in order to complete it.
SP3.2Assemble product components according to the product
integration strategy and procedures.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: b) reviews are conducted to evaluate
the ability of the results of design and
development to meet requirements
Continuous Integration is the ScrumXP practice
of working from the latest version of code and
integrating code components as often as
possible as soon as they are ready.
The SAFe® practice (from ScrumXP) of
Continuous Integration/Continuous Build
requires members of Agile Teams to integrate
their code at least once per Iteration (preferably
more often), and Teams within ARTs to
integrate their code at least partially several
times within a Program Increment (PI).
For early integration and built-in quality,
Suppliers and Agile Release Trains (ARTs)
should share interfaces, tests, and simulators,
which should be documented in the Solution
Intent for reference.
The Release Sprint may include enterprise-wide
system integration of the product as an item in
the Sprint Backlog.
A Scaled Definition of Done may require the
Release to have end-to-end integration and
solution V&V done, and for regression testing to
be completed.
SP3.3Evaluate assembled product components for interface
compatibility.
8.3: Design and development of products and
services: 8.3.5: Design and development
outputs: a) meet the input requirements; b) are
adequate for the subsequent processes for the
provision of products and services; c) include or
reference monitoring and measuring
requirements, as appropriate, and acceptance
criteria;
The Define-Build-Test lifecycle is used for each
user story in order to complete it.
The Define-Build-Test lifecycle is used for each
Story in order to complete it.
The Product Owner Review verifies that
completed user stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
Appraisal Considerations:
- “This evaluation involves examining and testing assembled product components
for performance, suitability, or readiness using the available procedures and
environment.”
- Beware of interpreting this practice too narrowly and focusing simply on
interfaces; note that, outside of the SP statement itself and TWP #2, the word
“interface” does not appear anywhere in the informative material (descriptive text,
subpractices). Rather, consider the ability of the integrated components to
cooperatively satisfy their intended purpose (functionality, performance, etc.)
Interface compatibility is a key part of this, but compatibility may be determined
explicitly or implicitly.
- It may be useful to think of this practice in terms of a “checkout”, which was the
terminology used for this SP in v1.02. See introductory text for Goal 3: “These
assembled product components are checked out for correct interoperation.” Refer
to the Verification and Validation process areas for more information on verifying
and validating the assembled product components.
- In practice, the assembly and evaluation of product components is often
performed together,
and it may be difficult to objectively distinguish these as discrete activities. See
SP3.2 for additional objective evidence that could be useful here.
Artifact Examples:
- Exception reports
- Interface evaluation reports
- Product integration summary reports
- Discrepancies detected during checkout of product components
- Milestones for completion of integration activities
- Evaluation results (e.g. adaptations, configuration, deviations)
- Logbook of product component issues or parameters.
- Product integration sequence (ref. SP1.1)
- Product integration procedures and criteria (ref. SP1.3)
- Regression testing procedures and results
Appraisal Considerations:
- “The purpose of this specific practice is to ensure that the properly identified
product component that meets its description can actually be assembled according
to the product integration sequence and available procedures.”
- Readiness is determined relative to the integration plans and procedures
described in SP1.1-1, SP1.2-2, and SP1.1-3.
- Only qualified components should be accepted for integration; see the Technical
Solution and Verification process areas for details on verifying individual product
components.
Artifact Example:
- Acceptance documents for received product components
- Verified acceptance test results or inspection report for product components
- Discrepancies identified in received product components
- Delivery receipts
- Checked packing lists
- Exception reports
- Waivers
- Configuration status reports for product components
- Product integration plans and procedures
- Criteria and checklists for product component readiness, delivery, integration,
and evaluation
Appraisal Considerations:
- This is a CL1 practice; when using the continuous representation, see the model
for guidance on appraising this practice relative to SP1.1 and SP1.3.
- Typically, the integration schedule and milestones are contained in the
integration plan. The plan should be reviewed periodically and revised as
appropriate.
Artifact Examples:
- Assembled product or product components
- Product integration sequence (ref. SP1.1)
- Product integration procedures and criteria (ref. SP1.3)
- Records indicating performance of the product integration sequence and
procedures (e.g., integration reports, completed checklists, configuration audits)
- Recorded configuration and assembly information (e.g., identification,
configuration status, calibration data).
- Integration status and schedule reports (e.g., planned vs. actual components
integrated)
- Revisions to the integration plans or procedures
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PI, Page 3
Page 82
Product Integration
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
A Scaled Definition of Done may require the
Release to have end-to-end integration and
solution V&V done, and for regression testing to
be completed.
SP3.4Package the assembled product or product component and deliver
it to the customer.Appraisal Considerations:
- Refer to the Verification PA and Validation PA for more information on verifying
and validating the assembled product before packaging, or upon deployment at
the operational site.
- Consider site installation and checkout in accordance with this practice, where
relevant, not just delivery.
Artifact Examples:
- Packaged product or product components
- Delivery documentation
- Packaging procedures
- Transportation and delivery procedures
- Packing list
- Certification for readiness of the operation site
- Site installation surveys and procedures
8.5: Production and service provision: 8.5.1:
Control of production and service provision: h)
the implementation of release, delivery and post-
delivery activities.
The Release Sprint typically includes preparing
code for deployment and deploying code to the
customer as items in the Sprint Backlog.
The release process may involve the transition
of solution assets or may require considerable
effort due to the nature of the Solution.
Appraisal Considerations:
- “This evaluation involves examining and testing assembled product components
for performance, suitability, or readiness using the available procedures and
environment.”
- Beware of interpreting this practice too narrowly and focusing simply on
interfaces; note that, outside of the SP statement itself and TWP #2, the word
“interface” does not appear anywhere in the informative material (descriptive text,
subpractices). Rather, consider the ability of the integrated components to
cooperatively satisfy their intended purpose (functionality, performance, etc.)
Interface compatibility is a key part of this, but compatibility may be determined
explicitly or implicitly.
- It may be useful to think of this practice in terms of a “checkout”, which was the
terminology used for this SP in v1.02. See introductory text for Goal 3: “These
assembled product components are checked out for correct interoperation.” Refer
to the Verification and Validation process areas for more information on verifying
and validating the assembled product components.
- In practice, the assembly and evaluation of product components is often
performed together,
and it may be difficult to objectively distinguish these as discrete activities. See
SP3.2 for additional objective evidence that could be useful here.
Artifact Examples:
- Exception reports
- Interface evaluation reports
- Product integration summary reports
- Discrepancies detected during checkout of product components
- Milestones for completion of integration activities
- Evaluation results (e.g. adaptations, configuration, deviations)
- Logbook of product component issues or parameters.
- Product integration sequence (ref. SP1.1)
- Product integration procedures and criteria (ref. SP1.3)
- Regression testing procedures and results
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PI, Page 4
Page 83
Verification
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1 Preparation for verification is conducted.
SP1.1Select work products to be verified and verification methods to be
used.
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: c) the required design and
development verification and validation
activities;
Test-Driven Development (TDD) is an XP
practice typically used in Agile development.
Built-in Quality, one of SAFe®'s Core Values, is
supported by the XP practice of Test-Driven
Development (TDD) and Acceptance Test-
Driven Development (ATDD), which are both
assisted by Automated Testing.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: b) reviews are conducted to evaluate
the ability of the results of design and
development to meet requirements;
The Define-Build-Test lifecycle is used for each
user story in order to complete it.
The Define-Build-Test lifecycle is used for each
Story in order to complete it.
SP1.2Establish and maintain the environment needed to support
verification.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: d)
the use of suitable infrastructure and
environment for the operation of processes;
Automated Testing tools and Unit Testing
Frameworks may be used as a part of Unit
Testing.
Automated Testing tools and Unit Testing
Frameworks may be used as a part of Unit and
Component Testing, User Acceptance Testing,
and System Qualities Testing. Manual testing is
usually used for System-level Acceptance
Testing but automated for most testing unless
manual testing is absolutely necessary.
Time and resources are allocated for testing
code according to the Define-Build-Test
lifecycle.
Time and resources are allocated for testing
code according to the Define-Build-Test
lifecycle.
SP1.3Establish and maintain verification procedures and criteria for the
selected work products.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: c) verification activities are conducted
to ensure that the design and development
outputs meet the input requirements;
Appraisal Considerations:
- Evidence should exist of the establishment and evolution of the verification
environment.
- A description of the verification environment and support tools is typically
contained in the verification plan.
Artifact Examples:
- Verification support equipment.
- Verification environment.
- Purchase orders of capital equipment, resource plans including hardware and
software (simulators, emulators, data reduction tools, interfaces with other
systems, etc.)
- Identification of reused and modified resources.
Appraisal Considerations:
- The intent of SG1 is to prepare ahead of time for the verification activities. We
would then expect to see defined verification methods (e.g., peer reviews, testing,
simulations, etc.), and identification of support tools, facilities, test equipment, etc.
Revision histories should exist as the verification strategy evolves.
- See model for example software verification methods (e.g., path testing,
operational scenario testing, etc.)
- Look for verification approaches implemented across the project or product
lifecycle (e.g., requirements verifiability)
- Example contents of a verification plan include verification mechanisms,
resources, environments.
- The list of work products subject to verification is identified in the Project
Planning PA.
Artifact Examples:
- Verification strategy
- Project verification plan
- Revisions to verification strategy and plan
- Revision history
- Commercial off the shelf (COTS) verification strategy.
- List of approved verification methods and processes (e.g., inspections, peer
reviews, analyses, testing)
- Requirements verification methods and verification criteria
- Verification environment requirements and support tools
- Verification procedures.
- Verification criteria.
- Verification criteria such as accuracy, precision, throughput, size, etc.
- Verification strategy
- Project verification plan
- Revisions to verification strategy and plan
- Revision history
- Commercial off the shelf (COTS) verification strategy.
- List of approved verification methods and processes (e.g., inspections, peer
reviews, analyses, testing)
- Requirements verification methods and verification criteria
- Verification environment requirements and support tools
- Verification procedures.
- Verification criteria.
- Verification criteria such as accuracy, precision, throughput, size, etc.
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VER, Page 1
Page 84
Verification
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.1: Operational planning and control: b)
establishing criteria for: 2) the acceptance of
products and services;
Test-Driven Development (TDD) is an XP
practice typically used in Agile development.
Built-in Quality, one of SAFe®'s Core Values, is
supported by the XP practice of Test-Driven
Development (TDD) and Acceptance Test-
Driven Development (ATDD), which are both
assisted by Automated Testing.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: f)
the validation, and periodic revalidation, of the
ability to achieve planned results of the
processes for production and service provision,
where the resulting output cannot be verified by
subsequent monitoring or measurement;
The Define-Build-Test lifecycle is used for each
user story in order to complete it.
The Define-Build-Test lifecycle is used for each
Story in order to complete it.
SG2 Peer Reviews are performed on selected work products.
SP2.1 Prepare for peer reviews of selected work products.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: c) verification activities are conducted
to ensure that the design and development
outputs meet the input requirements;
Peer review may be either performed at any
time during the workday (facilitated by
development team co-location) or scheduled to
set aside time specifically for reviewing code.
8.6: Release of products and services
Pair Programming is an XP practice typically
used in Agile development which involves two
people working on the same programming task.
Pair Work is the SAFe® practice supporting the
Core Value of Built-in Quality, and can be
performed by Agile Teams by using several
methods such as Pair Programming (from XP),
Story-based pairing, or spontaneous pairing for
critical work and challenges.
Collective Code Ownership is an XP practice
typically used in Agile development which
involves the creation and modification of the
same code by multiple team members.
Collective Code Ownership is an XP practice
typically used in Agile development which
involves the creation and modification of the
same code by multiple team members.
SP2.2Conduct peer reviews of selected work products and identify
issues resulting from these reviews.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: c) verification activities are conducted
to ensure that the design and development
outputs meet the input requirements;
Peer review may be either performed at any
time during the workday (facilitated by
development team co-location) or scheduled to
set aside time specifically for reviewing code.
Pair Work is the SAFe® practice supporting the
Core Value of Built-in Quality, and can be
performed by Agile Teams by using several
methods such as Pair Programming (from XP),
Story-based pairing, or spontaneous pairing for
critical work and challenges.
SP2.3Analyze data about the preparation, conduct, and results of the
peer reviews.
Appraisal Considerations:
- “Peer reviews should address the following guidelines: there must be sufficient
preparation, the conduct must be managed and controlled, consistent and
sufficient data must be recorded (an example is conducting a formal inspection),
and action items must be recorded.”
-See model for typical data collected from peer reviews
- Look for evidence that peer reviews are being performed as scheduled.
- Look for evidence of training for the performers.
Artifact Examples:
- Peer review results.
- Identified defects
- Peer review issues
- Action items
- Peer review data
- Data summarizing the conduct and results of the peer review
- Schedules showing peer reviews and re-review.
- Peer review data repository
- Completed peer review check lists
Appraisal Considerations:
- A peer review process typically includes items such as: checklists, entry/exit
criteria, identified roles and responsibilities, standards, review guidelines, etc.
Artifact Examples:
- Peer review schedule
- Re-review criteria
- Selected work products to be reviewed
- Peer review plans, processes, and schedules
- Peer review checklist
- Entry and exit criteria for work products
- Peer review training material
- Description of method chosen for the peer review such as inspections,
walkthroughs, etc.
- Peer review data package
- Peer review process that includes
Appraisal Considerations:
- Verification plans including the required resources and schedules may be part of
a larger overall plan and should be evident.
Artifact Examples:
- Verification plan, with detailed activities, schedules, resources
- List of work products and COTS products subject to verification
- Verification criteria
- Verification procedures
- Expected results and tolerances identified
- Equipment and environmental components identified
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VER, Page 2
Page 85
Verification
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: a) design and development changes;
The Product Owner Review verifies that
completed User Stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
8.5: Control of production and service provision:
8.5.3: Property belonging to customers or
external providers
The Sprint Retrospective meeting discusses
what processes went well and what did not in
the sprint, and what changes could be made to
improve the next sprint, involving the Product
Owner, Scrum Master, and development team.
The Iteration Retrospective evaluates what went
well and what did not go well in the last Iteration,
and what they can change to improve the next
Iteration.
SG3Selected work products are verified against their
specified requirements.SP3.1 Perform verification on selected work products.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: b) reviews are conducted to evaluate
the ability of the results of design and
development to meet requirements;
The Define-Build-Test lifecycle is used for each
user story in order to complete it.
The Define-Build-Test lifecycle is used for each
Story in order to complete it.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: c) verification activities are conducted
to ensure that the design and development
outputs meet the input requirements;
Peer review may be either performed at any
time during the workday (facilitated by
development team co-location) or scheduled to
set aside time specifically for reviewing code.
8.4: Control of externally provided processes,
products and services: 8.4.2: Type and extent of
control: d) determine the verification, or other
activities, necessary to ensure that the
externally provided processes, products and
services meet requirements.
The Product Owner Review verifies that
completed user stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
8.5: Production and service provision: 8.5.1:
Control of production and service provision: c)
the implementation of monitoring and
measurement activities at appropriate stages to
verify that criteria for control of processes or
outputs, and acceptance criteria for products
and services, have been met;
Practices that support the SAFe® Core Value of
Built-in Quality Core include Continuous
Integration, Test-First, Refactoring, Pair Work,
and Collective Ownership.
8.5: Production and service provision: 8.5.4:
Preservation
8.6: Release of products and services
SP3.2 Analyze results of all verification activities.
4.1: Understanding the organization and its
context
The Product Owner Review verifies that
completed user stories meet the Definition of
Done, which is captured on the Task Board.
The Product Owner verifies that completed
stories meet their acceptance tests, which is
captured on the Kanban board/story board.
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: a) design and development changes;
8.6: Release of products and services
Appraisal Considerations:
- None
Artifact Examples:
- Analysis report (such as statistics on performances, causal analysis of non-
conformances, comparison of the behavior between the product and models,
trends, etc.
- Corrective actions to verification methods, criteria, and/or infrastructure.
- Trouble reports.
- Method, criteria, and infrastructure change requests.
Appraisal Considerations:
- See model for typical content of data collected from peer reviews
Artifact Examples:
- Peer review data.
- Data recorded to reflect the conduct of the review (preparation, conduct and
results)
- Documented peer review analysis results
- Peer review action items.
- Peer review data repository
- Peer review metrics and analysis
- List of action items produced during peer reviews.
Appraisal Considerations:
- Look for Verification activities being conducted as scheduled.
- Verify that data is collected.
Artifact Examples:
- Verification results]
- Verification results such as:
- Test results
- Peer review results
- Verification reports
- (trouble reports, corrective action reports, presentations, etc.)
- “As Verified” procedures log
- Demonstrations
- Action items identified
- Requirements
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VER, Page 3
Page 86
Validation
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SG1 Preparation for validation is conducted.
SP1.1Select products and product components to be validated and
validation methods to be used.
8.1: Operational planning and control: b)
establishing criteria for: 2) the acceptance of
products and services;
The Sprint Review demonstrates the completed
Shippable Functionality of the sprint and allows
stakeholders to ask questions and provide
feedback on the product.
The Team, System, Solution Demos solicit
comments and feedback from stakeholders on
the Stories, Features, and Capabilities created
during the Iteration/PI/Value Stream.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: a) requirements specified
by the customer, including the requirements for
delivery and post-delivery activities;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: b) requirements not stated
by the customer, but necessary for the specified
or intended use, when known;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1:c) requirements specified
by the organization;
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: c) the required design and
development verification and validation
activities;
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: d) validation activities are conducted to
ensure that the resulting products and services
meet the requirements for the specified
application or intended use;
SP1.2Establish and maintain the environment needed to support
validation.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: a) requirements specified
by the customer, including the requirements for
delivery and post-delivery activities;
The Sprint Review demonstrates the completed
Shippable Functionality of the sprint and allows
stakeholders to ask questions and provide
feedback on the product.
The Team, System, Solution Demos solicit
comments and feedback from stakeholders on
the Stories, Features, and Capabilities created
during the Iteration/PI/Value Stream.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: b) requirements not stated
by the customer, but necessary for the specified
or intended use, when known;
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: g) the need for involvement of
customers and users in the design and
development process;
Appraisal Considerations:
- See model for validation strategy details
Artifact Examples:
- Validation strategy.
- Revisions to validation strategy
- Requirements defined for a realistic validation environment (includes operation,
maintenance, training and support delivered with product)
- Evaluation criteria defined.
- Stakeholder reviews conducted
- Validation plans and procedures
Appraisal Considerations:
- Consider arranging a tour or demonstration of the validation environment.
- See model for details regarding the validation environment
Artifact Examples:
- Validation environment.
- Revision history
- Purchase orders of capital equipment, resource plans including hardware and
software (test tools, simulators, temporary software, recording tools, interfaces
with other systems, computing environments, customer-supplied products, etc.).
- Resource plan, including reuse of existing resources.
- Validation procedures
- Validation criteria
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VAL, Page 1
Page 87
Validation
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
SP1.3 Establish and maintain procedures and criteria for validation.
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: a) requirements specified
by the customer, including the requirements for
delivery and post-delivery activities;
The Sprint Review demonstrates the completed
Shippable Functionality of the sprint and allows
stakeholders to ask questions and provide
feedback on the product.
The Team, System, Solution Demos solicit
comments and feedback from stakeholders on
the Stories, Features, and Capabilities created
during the Iteration/PI/Value Stream.
8.5: Control of production and service provision:
8.5.5: Post-delivery activities
SG2
The product or product components are validated to
ensure they are suitable for use in their intended
operating environment.
SP2.1 Perform validation on selected products and product components.
5.3: Organizational roles, responsibilities, and
authorities: b) ensuring that the processes are
delivering their intended outputs;
The Sprint Review demonstrates the completed
Shippable Functionality of the sprint and allows
stakeholders to ask questions and provide
feedback on the product.
The Team, System, Solution Demos solicit
comments and feedback from stakeholders on
the Stories, Features, and Capabilities created
during the Iteration/PI/Value Stream.
8.1: Operational planning and control: b)
establishing criteria for: 2) the acceptance of
products and services;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: a) requirements specified
by the customer, including the requirements for
delivery and post-delivery activities;
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.3.1: b) requirements not stated
by the customer, but necessary for the specified
or intended use, when known;
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: d) validation activities are conducted to
ensure that the resulting products and services
meet the requirements for the specified
application or intended use;
8.4: Control of externally provided processes,
products and services: 8.4.2: Type and extent of
control: d) determine the verification, or other
activities, necessary to ensure that the externally
provided processes, products and services meet
requirements.
Appraisal Considerations:
- Refer to SP1.1 for the Validation strategy.
- The validation cross reference matrix is assumed to provide a mapping from the
validation results to/from the validation requirements.
Artifact Examples:
- Validation reports.
- Validation results
- As-run procedures log.
- Validation cross-reference matrix.
- Operational demonstrations.
- Documented validation environment
- Data collected from performing validation procedures
- List of deviations encountered.
Appraisal Considerations:
- None
Artifact Examples:
- Validation procedures
- Validation criteria.
- Test and evaluation procedures for maintenance, training, and support.
- Product requirements
- Acceptance test cases
- Documented environment, operational scenario, inputs, outputs and expected
results.
- Design revisions
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VAL, Page 2
Page 88
Validation
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
8.4: Control of externally provided processes,
products and services: 8.4.3: Information for
external providers: f) verification or validation
activities that the organization, or its customer,
intends to perform at the external providers'
premises.
SP2.2 Analyze results of validation activities.
5.3: Organizational roles, responsibilities, and
authorities: b) ensuring that the processes are
delivering their intended outputs;
New User Stories may be generated from the
Sprint Review.
New Stories may be generated from the Team
Demo/System Demo.
8.3: Design and development of products and
services: 8.3.4: Design and development
controls: d) validation activities are conducted to
ensure that the resulting products and services
meet the requirements for the specified
application or intended use;
The Product Backlog is updated to add new
user stories and user stories that were not
completed during the sprint.
The Backlog is updated to add new Stories and
Stories that were not completed during the
Iteration/PI.
Appraisal Considerations:
- Refer to SP1.1 for the Validation strategy.
- The validation cross reference matrix is assumed to provide a mapping from the
validation results to/from the validation requirements.
Artifact Examples:
- Validation reports.
- Validation results
- As-run procedures log.
- Validation cross-reference matrix.
- Operational demonstrations.
- Documented validation environment
- Data collected from performing validation procedures
- List of deviations encountered.
Appraisal Considerations:
- The validation data results are compared against the evaluation criteria
established in SP1.3
Artifact Examples:
- Validation deficiency reports
- Validation issues.
- Analysis reports
- Validation results
- Procedure change request.
- Validation evaluation criteria
- Comparison of actual vs. expected results (e.g., measurements and performance
data)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VAL, Page 3
Page 89
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
GG2 The process is institutionalized as a managed process.
GP2.1Establish and maintain an organizational policy for planning and
performing the process.
5.2: Policy: 5.2.1: Establishing the quality policy
GP2.2 Establish and maintain the plan for performing the process.
6.2: Quality objectives and planning to achieve
them: 6.2.2
6.3: Planning of changes
Appraisal Considerations:
- “The purpose of this generic practice is to determine what is needed to perform
the process and achieve the established objectives, to prepare a plan for
performing the process, to prepare a process description, and to get agreement on
the plan from relevant stakeholders.”
- See GP 2.2 description in front matter for more details on what is expected and
typical plan contents; e.g., process description; standards; requirements;
objectives; dependencies; resources; responsibilities; training,; work products to
be placed under configuration management; measurements; stakeholder
involvement; monitoring; objective evaluation; management review.
- “Establishing a plan includes documenting the plan and providing a process
description. Maintaining the plan includes changing it as necessary, in response to
either corrective actions or to changes in requirements and objectives for the
process.” It is permissible for the plan not to have changed if none of these
conditions have occurred.
- The plan for performing the process “may be a standalone document, embedded
in a more comprehensive document, or distributed across multiple documents.” It
may be part of the project plan established in the Project Planning PA.
- GP2.2 establishes the plans for performing the process, which are implemented
in GP2.3 through GP2.10 in accordance with the plan.
- "Typically this plan for performing the requirements management process is a
part of the project plan as described in the Project Planning process area."
Elaboration: This plan for performing the requirements management process can
be part of (or referenced by) the project plan as described in the Project Planning
process area.
Artifact Example:
- Documented plan for performing the process.
- Revisions to the plan, as necessary.
- See Project Planning PA
- Requirements management plan
- Documented requirements and objectives for the process (e.g., quality, cost,
schedule).
- Documented process descriptions, including standards and procedures; this may
be included as part of the plan or by reference.
- Schedules and resources (funding, people, tools) established for performing the
process.
- Measures tracking and controlling progress of the plan.
- Evidence of review and agreement to the plan by relevant stakeholders (e.g.,
signature, approval, meeting minutes).
Appraisal Considerations:
- Policies should demonstrate management commitment and establish
expectations for the processes to be performed, e.g., “this is the way we do
business here”. Other terms besides “policy” may be used in the organizational
context to capture this.
- Policies need not be specified separately for each PA (1-to-1); a single policy
can cover multiple PAs.
- Policies are typically high-level. The structure of established policies should fit
the organization, not necessarily the CMMI model; i.e., not all PAs or SPs need to
be explicitly mentioned, this might be implicitly required by invoking applicable
processes and procedures. However, the linkage between PAs, policies, and
processes should be discernable to ensure coverage.
- Policies should be visible to those in the organization that are affected (e.g.,
intranet web access). However, recognize that the day-to-day work of engineers
does not typically deal with the policies; moreso the processes that comply with
the policies.
- Policies could exist at multiple levels within the organization (e.g. corporate,
division, department, etc.)
- A documented and approved waiver to the policy does not count against the
satisfaction of this GP.
- “This policy establishes organizational expectations for managing requirements
and identifying inconsistencies between the requirements and the project plans
and work products.”
Elaboration: This policy establishes organizational expectations for managing
requirements and identifying inconsistencies between the requirements and
project plans and work products.
Artifact Example:
- Organizational policy
- Version, date, or revision history indicating maintenance of the policies over
time.
- Repository of policies (e.g., intranet web access) making them visible and
accessible to the organization
- Mapping of policies to CMMI process areas
- Organizational process architecture, e.g., linkage of policies, processes,
procedures
- Signature of policies by authorized senior manager
- Audit results for implementation of the policies.
5.2: Policy: 5.2.2: Communicating the quality
policy
Generic Practices (All Process Areas)
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 1
Page 90
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
GP2.3
Provide adequate resources for performing the process,
developing the work products, and providing the services of the
process.
4.4: Quality management system and its
processes: 4.4.1: d) determine the resources
needed for these processes and ensure their
availability;
5.1: Leadership and commitment: 5.1.1:
General: e) ensuring that the resources needed
for the quality management are available;
6.2: Quality objectives and planning to achieve
them: 6.2.2: b) what resources will be required;
6.3: Planning of changes: c) the availability of
resources;
7.1: Resources: 7.1.1: General
7.1: Resources: 7.1.2: People
7.1: Resources: 7.1.3: Infrastructure
7.1: Resources: 7.1.4: Environment for the
operation of processes
Appraisal Considerations:
- “The purpose of this generic practice is to determine what is needed to perform
the process and achieve the established objectives, to prepare a plan for
performing the process, to prepare a process description, and to get agreement on
the plan from relevant stakeholders.”
- See GP 2.2 description in front matter for more details on what is expected and
typical plan contents; e.g., process description; standards; requirements;
objectives; dependencies; resources; responsibilities; training,; work products to
be placed under configuration management; measurements; stakeholder
involvement; monitoring; objective evaluation; management review.
- “Establishing a plan includes documenting the plan and providing a process
description. Maintaining the plan includes changing it as necessary, in response to
either corrective actions or to changes in requirements and objectives for the
process.” It is permissible for the plan not to have changed if none of these
conditions have occurred.
- The plan for performing the process “may be a standalone document, embedded
in a more comprehensive document, or distributed across multiple documents.” It
may be part of the project plan established in the Project Planning PA.
- GP2.2 establishes the plans for performing the process, which are implemented
in GP2.3 through GP2.10 in accordance with the plan.
- "Typically this plan for performing the requirements management process is a
part of the project plan as described in the Project Planning process area."
Elaboration: This plan for performing the requirements management process can
be part of (or referenced by) the project plan as described in the Project Planning
process area.
Artifact Example:
- Documented plan for performing the process.
- Revisions to the plan, as necessary.
- See Project Planning PA
- Requirements management plan
- Documented requirements and objectives for the process (e.g., quality, cost,
schedule).
- Documented process descriptions, including standards and procedures; this may
be included as part of the plan or by reference.
- Schedules and resources (funding, people, tools) established for performing the
process.
- Measures tracking and controlling progress of the plan.
- Evidence of review and agreement to the plan by relevant stakeholders (e.g.,
signature, approval, meeting minutes).
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: a) the nature, duration and complexity
of the design and development activities; b) the
required process stages, including applicable
design and development reviews;
Appraisal Considerations:
- Ensure the resources necessary to perform the process as defined by the plan
are available when they are needed.
- “Resources include adequate funding, appropriate physical facilities, skilled
people, and appropriate tools.”
- “The interpretation of the term ‘adequate’ depends on many factors and may
change over time.” Adequacy is subjective, and most likely determined through
affirmations of sufficiency from those performing the work. Listen also for cases
where the process failed due to insufficient resources. This may indicate
weaknesses in the plan or in the implementation.
- Care should be taken in relying on affirmations of "inadequate" resources. A
performer often wishes they had more time, money, or tools, but still has
"adequate" resources to accomplish their planned tasks.
- Separate budgets are not needed for each PA; they may be distributed over
several PAs. A key consideration is whether the manager of that process has
sufficient visibility to recognize the need for more resources.
Elaboration: Examples of resources provided include the following:
• Requirements tracking tools
• Traceability tools
Artifact Example:
- Documented process descriptions and plans (strategic or tactical) for performing
the process, which include a characterization of resources needed. (Reference
GP2.2)
- Evidence that adequate resources (funding, facilities, skilled people, tools, etc.)
are actually provided as planned.
- Staffing profiles and labor reports showing effort spent on performing the
process.
- Documented skill prerequisites for filling process roles and responsibilities, and
evidence that assigned staff meet these criteria.
- Development environment and facilities (hardware, software, licenses, tools,
labs, test equipment, etc.).
- Cost performance measures showing provision of funding in accordance with the
plan.
- Analyses, reports, or metrics tracking availability of resources vs. plan.
- [Tools: requirements tracking tools; traceability tools]
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 2
Page 91
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
8.1: Operational planning and control: c)
determining the resources needed to achieve
conformity to the product and service
requirements;
GP2.4
Assign responsibility and authority for performing the process,
developing the work products, and providing the services of the
process.
4.4: Quality management system and its
processes: 4.4.1: e) assign the responsibilities
and authorities for these processes;
5.3: Organizational roles, responsibilities and
authorities
6.2: Quality objectives and planning to achieve
them: 6.2.2: c) who will be responsible;
6.3: Planning of changes: d) the allocation or
reallocation of responsibilities and authorities;
GP2.5 Train the people performing or supporting the process as needed.
5.2: Policy: 5.2.2: Communicating the quality
policy: b) be communicated, understood and
applied within the organization;
7.1: Resources: 7.1.6: Organizational
knowledge
7.2: Competence
Appraisal Considerations:
- The training provided may be formal (e.g., classroom, CBT) or informal (e.g.,
structured mentoring), and may vary according to assigned role (e.g. detailed
training for those performing the work, orientation overview provided to those who
interact or support those performing the work).
- Consider other methods besides formal classroom training that might be used
(e.g., CBT, mentoring, videotapes). The method should ensure that skills and
knowledge are impacted.
- Recognize that training need not be provided on a PA basis; a single training
course could cover multiple processes.
- An approved waiver, stating that an individual possesses the skills and
knowledge imparted in the course, is equivalent to having received training.
- It is impractical that 100% of the performers of a process are trained at any point
in time, due to new hires, transfers, promotions, etc. Judgment is called for in
determining whether an excessive number of people are untrained.
- See GP elaborations for examples of training topics that might be included for
each PA. These elaborations are quoted from the model.
- “Examples of training topics include the following:
- Application domain
- Requirements definition, analysis, review, and management
- Requirements management tools
- Configuration management
- Negotiation and conflict resolution”
Elaboration: Examples of training topics include the following:
• Application domain
• Requirements definition, analysis, review, and management
• Requirements management tools
• Configuration management
• Negotiation and conflict resolution
Artifact Example:
- Training courses, materials, and methods.
- Training records (e.g., attendance, course descriptions, evaluation forms).
- Qualifications and criteria defined for process tasks and assignments.
- Training waiver criteria and approvals.
- Skills matrix or database.
- Training plans, and delivery of training according to the plan.
- Training effectiveness data (e.g., surveys, exams, feedback forms).
Appraisal Considerations:
- Ensure the resources necessary to perform the process as defined by the plan
are available when they are needed.
- “Resources include adequate funding, appropriate physical facilities, skilled
people, and appropriate tools.”
- “The interpretation of the term ‘adequate’ depends on many factors and may
change over time.” Adequacy is subjective, and most likely determined through
affirmations of sufficiency from those performing the work. Listen also for cases
where the process failed due to insufficient resources. This may indicate
weaknesses in the plan or in the implementation.
- Care should be taken in relying on affirmations of "inadequate" resources. A
performer often wishes they had more time, money, or tools, but still has
"adequate" resources to accomplish their planned tasks.
- Separate budgets are not needed for each PA; they may be distributed over
several PAs. A key consideration is whether the manager of that process has
sufficient visibility to recognize the need for more resources.
Elaboration: Examples of resources provided include the following:
• Requirements tracking tools
• Traceability tools
Artifact Example:
- Documented process descriptions and plans (strategic or tactical) for performing
the process, which include a characterization of resources needed. (Reference
GP2.2)
- Evidence that adequate resources (funding, facilities, skilled people, tools, etc.)
are actually provided as planned.
- Staffing profiles and labor reports showing effort spent on performing the
process.
- Documented skill prerequisites for filling process roles and responsibilities, and
evidence that assigned staff meet these criteria.
- Development environment and facilities (hardware, software, licenses, tools,
labs, test equipment, etc.).
- Cost performance measures showing provision of funding in accordance with the
plan.
- Analyses, reports, or metrics tracking availability of resources vs. plan.
- [Tools: requirements tracking tools; traceability tools]
Appraisal Considerations:
- “…ensure that there is accountability throughout the life of the process for
performing the process and achieving the specified results. The people assigned
must have the appropriate authority to perform the assigned responsibilities.”
- Responsibility assignments may be to individuals or groups, and may vary
across the life of the process.
- Ensure that the people assigned are available to do the work.
- Assignments may be defined in various ways; e.g., work authorizations, job
descriptions, project plans.
- Many PAs will have the various goals/practices assigned to different people;
make sure the entire PA has been assigned
- Look to make sure requirements management activities are assigned at each
appropriate level (e.g. system, subsystem, unit)
Artifact Example:
- Documentation assigning responsibility for process activities, work products, or
services; e.g., job descriptions, or plans for performing the process (see GP2.2).
- Task descriptions and activities for defined roles.
- Acceptance of responsibility by those assigned; this might be documented in
many ways (e.g., signature, commitment, agreement, appearance on an org chart,
web page contacts, etc.)
- Assignment is often in the project plan
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 3
Page 92
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
GP2.6Place selected work products of the process under appropriate
levels of control.
7.5: Documented information: 7.5.1: General
7.5: Documented information: 7.5.2: Creating
and updating
7.5: Documented information: 7.5.3: Control of
documented information
Appraisal Considerations:
- This GP is enabled by the CM PA; refer to that PA for additional information on
configuration management practices.
- Ensure the work products are controlled and revised in accordance with the
documented plans for the PA being examined.
- Consider the key phrases here: (1) “designated” work products; (2) “appropriate
levels” of configuration management. In other words, the formality may vary
according to the work product (e.g., version control vs. configuration management)
– see GP2.6 description in the front matter for further description.
- In examining the work products identified for each PA below, “different versions”
are recognizable by version labels, distribution dates, change histories, etc.
- “Different levels of configuration management are appropriate for different work
products and for different points in time.” It is up to the project or organization to
define what level of CM they have determined is adequate for each work product.
- Examples of work products placed under CM include the following:
• Requirements
• Requirements traceability matrix”
Elaboration: Examples of work products placed under control include the
following:
• Requirements
• Requirements traceability matrix
Artifact Example:
- List of work products identified for configuration management and the level of
configuration management for each work product is identified
- Work products that are under configuration management (e.g., work products
having version identifiers, change histories)
- Change control documentation (e.g., change requests, problem reports, status
reports indicating disposition)
- Baselines and a description of their contents.
- Configuration management life cycle for identified work products, i.e., the point at
which products are placed under various levels of control, change control
authority, etc.
- Configuration management processes, populated repository, and tools.
- CCB meeting minutes
- Written status of work products (e.g., in-work, in review, accepted for baseline,
etc.)
- Requirements baselines, change requests, and reports indicating requirements
status (e.g., proposed, reviewed, approved)
Appraisal Considerations:
- The training provided may be formal (e.g., classroom, CBT) or informal (e.g.,
structured mentoring), and may vary according to assigned role (e.g. detailed
training for those performing the work, orientation overview provided to those who
interact or support those performing the work).
- Consider other methods besides formal classroom training that might be used
(e.g., CBT, mentoring, videotapes). The method should ensure that skills and
knowledge are impacted.
- Recognize that training need not be provided on a PA basis; a single training
course could cover multiple processes.
- An approved waiver, stating that an individual possesses the skills and
knowledge imparted in the course, is equivalent to having received training.
- It is impractical that 100% of the performers of a process are trained at any point
in time, due to new hires, transfers, promotions, etc. Judgment is called for in
determining whether an excessive number of people are untrained.
- See GP elaborations for examples of training topics that might be included for
each PA. These elaborations are quoted from the model.
- “Examples of training topics include the following:
- Application domain
- Requirements definition, analysis, review, and management
- Requirements management tools
- Configuration management
- Negotiation and conflict resolution”
Elaboration: Examples of training topics include the following:
• Application domain
• Requirements definition, analysis, review, and management
• Requirements management tools
• Configuration management
• Negotiation and conflict resolution
Artifact Example:
- Training courses, materials, and methods.
- Training records (e.g., attendance, course descriptions, evaluation forms).
- Qualifications and criteria defined for process tasks and assignments.
- Training waiver criteria and approvals.
- Skills matrix or database.
- Training plans, and delivery of training according to the plan.
- Training effectiveness data (e.g., surveys, exams, feedback forms).
7.2: Awareness
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 4
Page 93
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
GP2.7Identify and involve the relevant stakeholders of the process as
planned.
4.2: Understanding the needs and expectations
of interested parties
8.2: Requirements for products and services:
8.2.1: Customer communication
8.2.4: Changes to requirements for products
and services
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: g) the need for involvement of
customers and users in the design and
development process;
8.5: Production and service provision: 8.5.5:
Post-delivery activities: e) customer feedback;
8.7: Control of nonconforming outputs: 8.7.1: c)
informing the customer; d) obtaining
authorization for acceptance under concession.
Appraisal Considerations:
- See GP2.7 description in front matter for typical activities for stakeholder
involvement (e.g., planning, decisions, communications, coordination,
assessments, requirements definitions, resolution of problems/issues.)
- “A “stakeholder” is a group or individual that is affected by or in some way
accountable for the outcome of an undertaking. Stakeholders may include project
members, suppliers, customers, end users, and others.”
- “The term “relevant stakeholder” is used to designate a stakeholder that is
identified for involvement in specified activities and is included in an appropriate
plan. (See the Plan Stakeholder involvement specific practice in the Project
Planning process area and the Identify and Involve Relevant Stakeholders generic
practice.)”
- The set of relevant stakeholders for each PA may vary across the life cycle or as
the organization increases its process capability/maturity.
- The identification and involvement of relevant stakeholders may vary according
to project characteristics and attributes (e.g., size, complexity, duration).
- In some PAs, candidate stakeholders are listed in the GP elaboration and can be
used for reference as appropriate.
- Include expected relevant stakeholders in the population of FAR group members
and ask questions regarding their involvement in project activities.
- Examples of activities for stakeholder involvement include:
• Resolving issues on the understanding of the requirements
• Assessing the impact of requirements changes
• Communicating the bidirectional traceability
• Identifying inconsistencies among project plans, work products, and
requirements
Elaboration: Select relevant stakeholders from customers, end users, developers,
producers, testers, suppliers, marketers, maintainers, disposal personnel, and
others who may be affected by, or may affect, the product as well as the process.
Examples of activities for stakeholder involvement include the following:
• Resolving issues on the understanding of requirements
• Assessing the impact of requirements changes
• Communicating bidirectional traceability
• Identifying inconsistencies among project plans, work products, and
requirements
Artifact Example:
- Documentation showing identification of relevant stakeholders (stakeholder list,
involvement matrix, memoranda, plans, distribution lists, Conops, etc.)
- Plans that identify relevant stakeholders and how they are involved.
- Evidence that stakeholders are involved as planned.
- Mechanisms and documentation of relevant stakeholder involvement (e-mail,
memoranda, meeting minutes, signature approval, charters, distribution lists,
attendance lists, reviews, surveys, reports, web pages, etc.)
- The plan for stakeholder involvement, as specified in the Project Planning PA.
This may be part of the project plan.
Appraisal Considerations:
- This GP is enabled by the CM PA; refer to that PA for additional information on
configuration management practices.
- Ensure the work products are controlled and revised in accordance with the
documented plans for the PA being examined.
- Consider the key phrases here: (1) “designated” work products; (2) “appropriate
levels” of configuration management. In other words, the formality may vary
according to the work product (e.g., version control vs. configuration management)
– see GP2.6 description in the front matter for further description.
- In examining the work products identified for each PA below, “different versions”
are recognizable by version labels, distribution dates, change histories, etc.
- “Different levels of configuration management are appropriate for different work
products and for different points in time.” It is up to the project or organization to
define what level of CM they have determined is adequate for each work product.
- Examples of work products placed under CM include the following:
• Requirements
• Requirements traceability matrix”
Elaboration: Examples of work products placed under control include the
following:
• Requirements
• Requirements traceability matrix
Artifact Example:
- List of work products identified for configuration management and the level of
configuration management for each work product is identified
- Work products that are under configuration management (e.g., work products
having version identifiers, change histories)
- Change control documentation (e.g., change requests, problem reports, status
reports indicating disposition)
- Baselines and a description of their contents.
- Configuration management life cycle for identified work products, i.e., the point at
which products are placed under various levels of control, change control
authority, etc.
- Configuration management processes, populated repository, and tools.
- CCB meeting minutes
- Written status of work products (e.g., in-work, in review, accepted for baseline,
etc.)
- Requirements baselines, change requests, and reports indicating requirements
status (e.g., proposed, reviewed, approved)
8.2: Requirements for products and services:
8.2.3: Review of the requirements for products
and services: 8.2.4: Changes to requirements
for products and services
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 5
Page 94
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
GP2.8Monitor and control the process against the plan for performing
the process and take appropriate corrective action.
4.4: Quality management system and its
processes: 4.4.1: c) determine and apply the
criteria and methods (including monitoring,
measurements and related performance
indicators) needed to ensure the effective
operation and control of these processes;
5.3: Organizational roles, responsibilities and
authorities: b) ensuring that the processes are
delivering their intended outputs;
6.2: Quality objectives and planning to achieve
them: 6.2.1: e) be monitored;
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.1: General
7.1: Resources: 7.1.5: Monitoring and
measuring resources: 7.1.5.2: Measurement
traceability
8.1: Operational planning and control: d)
implementing control of the processes in
accordance with the criteria;
Appraisal Considerations:
- See GP2.7 description in front matter for typical activities for stakeholder
involvement (e.g., planning, decisions, communications, coordination,
assessments, requirements definitions, resolution of problems/issues.)
- “A “stakeholder” is a group or individual that is affected by or in some way
accountable for the outcome of an undertaking. Stakeholders may include project
members, suppliers, customers, end users, and others.”
- “The term “relevant stakeholder” is used to designate a stakeholder that is
identified for involvement in specified activities and is included in an appropriate
plan. (See the Plan Stakeholder involvement specific practice in the Project
Planning process area and the Identify and Involve Relevant Stakeholders generic
practice.)”
- The set of relevant stakeholders for each PA may vary across the life cycle or as
the organization increases its process capability/maturity.
- The identification and involvement of relevant stakeholders may vary according
to project characteristics and attributes (e.g., size, complexity, duration).
- In some PAs, candidate stakeholders are listed in the GP elaboration and can be
used for reference as appropriate.
- Include expected relevant stakeholders in the population of FAR group members
and ask questions regarding their involvement in project activities.
- Examples of activities for stakeholder involvement include:
• Resolving issues on the understanding of the requirements
• Assessing the impact of requirements changes
• Communicating the bidirectional traceability
• Identifying inconsistencies among project plans, work products, and
requirements
Elaboration: Select relevant stakeholders from customers, end users, developers,
producers, testers, suppliers, marketers, maintainers, disposal personnel, and
others who may be affected by, or may affect, the product as well as the process.
Examples of activities for stakeholder involvement include the following:
• Resolving issues on the understanding of requirements
• Assessing the impact of requirements changes
• Communicating bidirectional traceability
• Identifying inconsistencies among project plans, work products, and
requirements
Artifact Example:
- Documentation showing identification of relevant stakeholders (stakeholder list,
involvement matrix, memoranda, plans, distribution lists, Conops, etc.)
- Plans that identify relevant stakeholders and how they are involved.
- Evidence that stakeholders are involved as planned.
- Mechanisms and documentation of relevant stakeholder involvement (e-mail,
memoranda, meeting minutes, signature approval, charters, distribution lists,
attendance lists, reviews, surveys, reports, web pages, etc.)
- The plan for stakeholder involvement, as specified in the Project Planning PA.
This may be part of the project plan.
9.2: Internal audit: 9.2.2: d) ensure that the
results of the audits are reported to relevant
management;
Appraisal Considerations:
- "The purpose of this practice is to perform the direct day-to-day monitoring and
controlling of the process. Appropriate visibility into the process is maintained so
that appropriate corrective action can be taken when necessary."
- “Reviews can be both periodic and event-driven.”
- This GP monitors and controls the plan for the process as specified in GP2.2.
- See GP description for typical corrective actions. Ensure that corrective actions
have been tracked to closure.
- Refer to the PMC PA for additional information on project monitoring and control.
- Refer to the MA PA for additional information about measurement.
- Examples of measures used in monitoring and controlling include the following:
• Requirements volatility (percentage of requirements changed)
Elaboration: Examples of measures and work products used in monitoring and
controlling include the following:
• Requirements volatility (percentage of requirements changed)
• Schedule for coordination of requirements
• Schedule for analysis of a proposed requirements change
Artifact Example:
- Measures of actual performance against plan (e.g., process, work products, and
services).
- Progress tracking reports, e.g. status reports, financials, graphs, analyses.
- Evidence of reviews of activities, status, and results of the process held with
immediate level of management responsible for the process and identification of
issues; (e.g. briefings, reports, presentations, milestones).
- Issues and corrective actions for deviations from plan (e.g., action items,
variance reports, change requests).
- Revisions and change history to plans and commitments (e.g., replanned
schedule, costs, resources).
- Number of clarifications to requirements
- Requirements counts, status, and traceability metrics
- Action items to resolve requirements discrepancies or inconsistencies relative to
project plans
- Impact assessments for requirements changesLast updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 6
Page 95
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
8.3: Design and development of products and
services: 8.3.2: Design and development
planning: i) the level of control expected for the
design and development process by customers
and other relevant interested parties;
GP2.9
Objectively evaluate adherence of the process and selected work
products against the process description, standards, and
procedures, and address noncompliance.
4.4: Quality management system and its
processes: 4.4.1: g) evaluate these processes
and implement any changes needed to ensure
that these processes achieve their intended
results;
5.1: Leadership and commitment: 5.1.1:
General: b) ensuring that the quality policy and
quality objectives are established for the quality
management system and are compatible with
the context and strategic direction of the
organization; g) ensuring that the quality
management system achieves its intended
results;
5.3: Organizational roles, responsibilities, and
authorities: a) ensuring that the quality
management system conforms to the
requirements of this International Standard; e)
ensuring that the integrity of the quality
management system is maintained when
changes to the quality management system are
planned and implemented.
6.2: Quality objectives and planning to achieve
them: 6.2.1: a) be consistent with the quality
policy;
6.3: Planning of changes: a) the purpose of the
changes and their potential consequences; b)
the integrity of the quality management system;
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.1: General
9.1: Monitoring, measurement, analysis and
evaluation: 9.1.3: Analysis and evaluation
9.2: Internal audit: 9.2.1
Appraisal Considerations:
- "The purpose of this practice is to perform the direct day-to-day monitoring and
controlling of the process. Appropriate visibility into the process is maintained so
that appropriate corrective action can be taken when necessary."
- “Reviews can be both periodic and event-driven.”
- This GP monitors and controls the plan for the process as specified in GP2.2.
- See GP description for typical corrective actions. Ensure that corrective actions
have been tracked to closure.
- Refer to the PMC PA for additional information on project monitoring and control.
- Refer to the MA PA for additional information about measurement.
- Examples of measures used in monitoring and controlling include the following:
• Requirements volatility (percentage of requirements changed)
Elaboration: Examples of measures and work products used in monitoring and
controlling include the following:
• Requirements volatility (percentage of requirements changed)
• Schedule for coordination of requirements
• Schedule for analysis of a proposed requirements change
Artifact Example:
- Measures of actual performance against plan (e.g., process, work products, and
services).
- Progress tracking reports, e.g. status reports, financials, graphs, analyses.
- Evidence of reviews of activities, status, and results of the process held with
immediate level of management responsible for the process and identification of
issues; (e.g. briefings, reports, presentations, milestones).
- Issues and corrective actions for deviations from plan (e.g., action items,
variance reports, change requests).
- Revisions and change history to plans and commitments (e.g., replanned
schedule, costs, resources).
- Number of clarifications to requirements
- Requirements counts, status, and traceability metrics
- Action items to resolve requirements discrepancies or inconsistencies relative to
project plans
- Impact assessments for requirements changes
Appraisal Considerations:
- "The purpose of this practice is to provide credible assurance that the process is
implemented as planned and adheres to its process description, standards, and
procedures.” This includes adherence of both the process and the products. It
covers organizational policies, customer requirements, and project procedures
and standards, if they exist.
- Projects may elect not to use additional procedures or standards beyond the
organizational policies.
- Objectivity is necessary, but independence is not necessarily required. Objective
reviews “can be done by independent groups, or by project members themselves.”
- “People not directly responsible for managing or performing the activities of the
process typically evaluate adherence. In many cases, adherence is evaluated by
people within the organization, but external to the process or project, or by people
external to the organization. As a result, credible assurance of adherence can be
provided even during times when the process is under stress (e.g., when the effort
is behind schedule or over budget).”
- Refer to PPQA PA for more information about the SG/SPs needed to objectively
evaluate adherence.
- Examples of activities reviewed include the following:
• Managing requirements
• Identifying inconsistencies among project plans, work products, and
requirements
- Examples of work products reviewed include the following:
• Requirements
• Requirements traceability matrix
- "Examples of measures used in monitoring and controlling include the following:
• Requirements volatility (percentage of requirements changed)"
Elaboration: Examples of activities reviewed include the following:
• Managing requirements
• Identifying inconsistencies among project plans, work products, and
requirements
Examples of work products reviewed include the following:
• Requirements
• Requirements traceability matrix
Artifact Example:
- Records of evaluations or audits being performed as planned (e.g., reports,
completed checklists).
- Noncompliance issues resulting from objective evaluation of adherence to
processes, objectives, and standards.
- Identification of processes, work products, and services to be objectively
evaluated.
- Criteria against which processes and work products are evaluated.
- Assignment of responsibility for performing objective evaluations (see GP2.4).
- Revised plans, work products, or standards reflecting corrective action resulting
from objective evaluations.
- Number of clarifications to requirements
- Requirements counts, status, and traceability metrics
- Action items to resolve requirements discrepancies or inconsistencies relative to
project plans
- Impact assessments for requirements changes
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 7
Page 96
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
9.2: Internal audit: 9.2.2
GP2.10Review the activities, status, and results of the process with higher
level management and resolve issues.
5.3: Organizational roles, responsibilities and
authorities: c) reporting on the performance of
the quality management system and on
opportunities for improvement, in particular to
top management;
8.3: Design and development of products and
services: 8.3.6: Design and development
changes: c) the authorization of the changes;
8.7: Control of nonconforming outputs: 8.7.1: d)
obtaining authorization for acceptance under
concession.
9.3: Management review: 9.3.1: General
9.3: Management review: 9.3.2: Management
review inputs
9.3: Management review: 9.3.3: Management
review outputs
GG3 The process is institutionalized as a defined process.
GP3.1 Establish and maintain the description of a defined process.
4.4: Quality management system and its
processes: 4.4.1
5.2: Policy: 5.2.1: Establishing the quality policy
Appraisal Considerations:
- “The purpose of this generic practice is to establish and maintain a description of
the process that is tailored from the organization’s set of standard processes to
address the needs of a specific instantiation.”
- See model for detailed description of a defined process.
- “A defined process is a managed process that is tailored from the organization's
set of standard processes according to the organization’s tailoring guidelines, and
contributes work products, measures, and other process-improvement information
to the organizational process assets.”
- Process descriptions may exist only at the organizational (not project) level.
Projects may also have processes that are not standardized at the organizational
level.
- See OPD for further guidance on the practices used to establish the standard
process
- See IPM SP1.1 on how to establish and maintain the project’s defined process
- A family of process descriptions may exist for use in different situations.
- Separate process description need not exist for every PA; process descriptions
may cover multiple PAs or part of a PA.
- "Establish and maintain" implies usage, so it is expected that the defined
processes are used by the projects or organization, tailored as appropriate, and
revised as necessary.
Artifact Example:
- Defined process description (purpose, inputs, entry criteria, activities, roles,
measures, verification steps, outputs, exit criteria) tailored from the organization’s
set of standard processes.
- Change records for the defined process descriptions.
- Records of how the organizational standard process was tailored for a particular
project or process application
- Artifacts showing that the defined process, as tailored, is followed
- Identification of the baseline of standard process used.
Appraisal Considerations:
- "The purpose of this practice is to provide higher-level management with the
appropriate visibility into the process."
- The purpose of the review is not to duplicate GP 2.8 Monitor and Control, but to
focus on whether the process, as implemented, is satisfying organizational goals
(e.g., employee morale, customer satisfaction).
- “These reviews are expected to be both periodic and event-driven.” The
periodicity of the reviews can be defined by the organization, but should be
frequent enough to address organizational issues. Typical event-driven reviews
would occur at the completion of a major phase of the life cycle.
- Reviews do not have to be face-to-face (e.g., submission and review of a status
report), but they must show evidence of manager review of pertinent information
- Proposed changes to commitments to be made external to the organization are
reviewed with higher level management to ensure that all commitments can be
accomplished.
Elaboration: Proposed changes to commitments to be made external to the
organization are reviewed with higher level management to ensure that all
commitments can be accomplished.
Direct Artifact Example:
- Materials and results from reviews (e.g. status reports and briefings) held with
higher-level management, on both a periodic and event-driven basis.
Indirect Artifact Example:
- Action items and corrective action resulting from management reviews.
- Metrics and analyses summarizing project status.
- Schedule for reviews held with higher-level management.
Appraisal Considerations:
- "The purpose of this practice is to provide credible assurance that the process is
implemented as planned and adheres to its process description, standards, and
procedures.” This includes adherence of both the process and the products. It
covers organizational policies, customer requirements, and project procedures
and standards, if they exist.
- Projects may elect not to use additional procedures or standards beyond the
organizational policies.
- Objectivity is necessary, but independence is not necessarily required. Objective
reviews “can be done by independent groups, or by project members themselves.”
- “People not directly responsible for managing or performing the activities of the
process typically evaluate adherence. In many cases, adherence is evaluated by
people within the organization, but external to the process or project, or by people
external to the organization. As a result, credible assurance of adherence can be
provided even during times when the process is under stress (e.g., when the effort
is behind schedule or over budget).”
- Refer to PPQA PA for more information about the SG/SPs needed to objectively
evaluate adherence.
- Examples of activities reviewed include the following:
• Managing requirements
• Identifying inconsistencies among project plans, work products, and
requirements
- Examples of work products reviewed include the following:
• Requirements
• Requirements traceability matrix
- "Examples of measures used in monitoring and controlling include the following:
• Requirements volatility (percentage of requirements changed)"
Elaboration: Examples of activities reviewed include the following:
• Managing requirements
• Identifying inconsistencies among project plans, work products, and
requirements
Examples of work products reviewed include the following:
• Requirements
• Requirements traceability matrix
Artifact Example:
- Records of evaluations or audits being performed as planned (e.g., reports,
completed checklists).
- Noncompliance issues resulting from objective evaluation of adherence to
processes, objectives, and standards.
- Identification of processes, work products, and services to be objectively
evaluated.
- Criteria against which processes and work products are evaluated.
- Assignment of responsibility for performing objective evaluations (see GP2.4).
- Revised plans, work products, or standards reflecting corrective action resulting
from objective evaluations.
- Number of clarifications to requirements
- Requirements counts, status, and traceability metrics
- Action items to resolve requirements discrepancies or inconsistencies relative to
project plans
- Impact assessments for requirements changes
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 8
Page 97
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
5.3: Organizational roles, responsibilities, and
authorities: e) ensuring that the integrity of the
quality management system is maintained when
changes to the quality management system are
planned and implemented.
GP3.2
Collect process related experiences derived from planning and
performing the process to support the future use and improvement
of the organization’s processes and process assets.
9.3: Management review: 9.3.2: Management
review inputs: f) opportunities for improvement
9.3: Management review: 9.3.3: Management
review outputs: a) opportunities for
improvement;
10.1: General
10.2: Nonconformity and corrective action: f)
make changes to the quality management
system, if necessary.
Appraisal Considerations:
- “The purpose of this generic practice is to establish and maintain a description of
the process that is tailored from the organization’s set of standard processes to
address the needs of a specific instantiation.”
- See model for detailed description of a defined process.
- “A defined process is a managed process that is tailored from the organization's
set of standard processes according to the organization’s tailoring guidelines, and
contributes work products, measures, and other process-improvement information
to the organizational process assets.”
- Process descriptions may exist only at the organizational (not project) level.
Projects may also have processes that are not standardized at the organizational
level.
- See OPD for further guidance on the practices used to establish the standard
process
- See IPM SP1.1 on how to establish and maintain the project’s defined process
- A family of process descriptions may exist for use in different situations.
- Separate process description need not exist for every PA; process descriptions
may cover multiple PAs or part of a PA.
- "Establish and maintain" implies usage, so it is expected that the defined
processes are used by the projects or organization, tailored as appropriate, and
revised as necessary.
Artifact Example:
- Defined process description (purpose, inputs, entry criteria, activities, roles,
measures, verification steps, outputs, exit criteria) tailored from the organization’s
set of standard processes.
- Change records for the defined process descriptions.
- Records of how the organizational standard process was tailored for a particular
project or process application
- Artifacts showing that the defined process, as tailored, is followed
- Identification of the baseline of standard process used.
Appraisal Considerations:
- “The purpose of this generic practice is to collect information and artifacts
derived from planning and performing the process. This generic practice is
performed so that the information and artifacts can be included in the
organizational process assets and made available to those who are (or who will
be) planning and performing the same or similar processes. The information and
artifacts are stored in the organization’s measurement repository and the
organization’s process asset library.”
- “Examples of relevant information include the effort expended for the various
activities, defects injected or removed in a particular activity, and lessons learned.”
- Material is collected from across the organization. Appropriate levels of security
should be defined so that information is accessible to those who need it. “The
process and product measures are primarily those that are defined in the common
set of measures for the organization’s standard processes.”
- Refer to OPD PA for more information about the organizational measurement
repository and organizational process asset library.
- See the elaborations of GP2.8 (Monitor and Control the Process) for typical
measures that could be collected.
Elaboration: Examples of work products, measures, measurement results, and
improvement information include the following:
• Requirements traceability matrix
• Number of unfunded requirements changes after baselining
• Lessons learned in resolving ambiguous requirements
Artifact Example:
- Collected work products (e.g., documentation) for inclusion in the organizational
library of process-related assets.
- Collected process and product measures and measurement results (see GP2.8
elaborations for examples)
- Collected improvement information (e.g. lessons learned, proposed
improvements)
Note: the CMMI model does not provide elaborations or examples on improvement
information that may be applicable for each process area. The work products
listed in the PAs below (obtained primarily from typical work products of
associated specific practices) suggest example work products, measures and
measurement results that may be part of the improvement information collected.
Not all of these examples may be relevant for a given organization, or have
sufficient business value to collect and maintain at the organizational level. The
organization is responsible for identifying and defining which work products,
measures, measurement results and improvement information they think is
important to collect to support future use and improvement of the organization’s
assets.
- Changes resulting from incorporation of improvement information
- Requests for submitting documentation to the organizational process library
- Improvement proposals
- Descriptions of common set of product and process measures for the
organization’s processes and process assets
- Populated organizational measurement repository and associated analyses
- Processes and procedures for submission, incorporation, and maintenance of
assets in the organizational library
- Populated organizational process library
- Catalog of process documentation items that exist in the library
- Plans, processes, and procedures for performing the process area
- Requirements documents and measures
- Requirements database schema and repository
- Requirements traceability matrices
- Defects identified in requirements peer reviews
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 9
Page 98
CMMI® Key Practices / Notes ISO 9001:2015 QMS Clauses Agile (Scrum+Kanban) Artifacts & Ceremonies SAFe® 4.0 Practices and Principles
Generic Practices (All Process Areas)
10.3: Continual improvement
Appraisal Considerations:
- “The purpose of this generic practice is to collect information and artifacts
derived from planning and performing the process. This generic practice is
performed so that the information and artifacts can be included in the
organizational process assets and made available to those who are (or who will
be) planning and performing the same or similar processes. The information and
artifacts are stored in the organization’s measurement repository and the
organization’s process asset library.”
- “Examples of relevant information include the effort expended for the various
activities, defects injected or removed in a particular activity, and lessons learned.”
- Material is collected from across the organization. Appropriate levels of security
should be defined so that information is accessible to those who need it. “The
process and product measures are primarily those that are defined in the common
set of measures for the organization’s standard processes.”
- Refer to OPD PA for more information about the organizational measurement
repository and organizational process asset library.
- See the elaborations of GP2.8 (Monitor and Control the Process) for typical
measures that could be collected.
Elaboration: Examples of work products, measures, measurement results, and
improvement information include the following:
• Requirements traceability matrix
• Number of unfunded requirements changes after baselining
• Lessons learned in resolving ambiguous requirements
Artifact Example:
- Collected work products (e.g., documentation) for inclusion in the organizational
library of process-related assets.
- Collected process and product measures and measurement results (see GP2.8
elaborations for examples)
- Collected improvement information (e.g. lessons learned, proposed
improvements)
Note: the CMMI model does not provide elaborations or examples on improvement
information that may be applicable for each process area. The work products
listed in the PAs below (obtained primarily from typical work products of
associated specific practices) suggest example work products, measures and
measurement results that may be part of the improvement information collected.
Not all of these examples may be relevant for a given organization, or have
sufficient business value to collect and maintain at the organizational level. The
organization is responsible for identifying and defining which work products,
measures, measurement results and improvement information they think is
important to collect to support future use and improvement of the organization’s
assets.
- Changes resulting from incorporation of improvement information
- Requests for submitting documentation to the organizational process library
- Improvement proposals
- Descriptions of common set of product and process measures for the
organization’s processes and process assets
- Populated organizational measurement repository and associated analyses
- Processes and procedures for submission, incorporation, and maintenance of
assets in the organizational library
- Populated organizational process library
- Catalog of process documentation items that exist in the library
- Plans, processes, and procedures for performing the process area
- Requirements documents and measures
- Requirements database schema and repository
- Requirements traceability matrices
- Defects identified in requirements peer reviews
Last updated 8/20/17This crosswalk is copyright of Excellence in Measurement Technology, 2017. All rights reserved.
Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 10