The EMT CMMI /ISO 9001/Agile/SAFe Crosswalk · Excellence in Measurement Technology presents: The EMT CMMI®/ISO 9001/Agile/SAFe® Crosswalk How to use this crosswalk: This crosswalk

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

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/.


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Instructions, Page 2

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.






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.



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.







reviewing and analysing the nonconformity; 2)


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


- 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)



- Metrics Analysis Report

- Cause & Effect Diagrams

- Meeting minutes of Defect Prevention Meeting

- Meeting minutes from Causal Analysis session


- Defect Analysis Form


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CAR, Page 1

Causal Analysis and Resolution


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.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.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



- Experience report of using CAR data


- Organization knowledge repository


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.











- 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


- Implemented Defect Prevention action plan


- CAR process status sheet


- 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 )


- Closure of Defect Prevention Action(s)


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CAR, Page 2

Configuration Management


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


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.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;



controls: f) documented information of these

activities is retained.


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. CM, Page 1



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.


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.








SAFe® Solution Intent practices for

documenting requirements, design, and

architecture include documenting items in only

one place.



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.


management system

User Stories establish requirement baselines

and are used to track requirements until

completion.








The Sprint Backlog shows all of the user stories

in a sprint and related tasks.



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


- “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


- 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)


- 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





SG2Changes to the work products under configuration

management are tracked and controlled.SP2.1 Track change requests for configuration items.


management system

The Product Owner is responsible for creating

and maintaining the Product Backlog by adding

and prioritizing User Stories.


and maintaining the Team Backlog by adding

and prioritizing Stories.








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.


Control of changes



changes: c) the authorization of the changes;

SP2.2 Control changes to configuration items.


management system







management.



















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;


and updating




Control of changes




SG3 Integrity of baselines is established and maintained


- 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


- 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.





SP3.1 Establish and maintain records describing configuration items.


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).













standards.


and updating: a) identification and description;


Control of changes

SP3.2Perform configuration audits to maintain the integrity of

configuration baselines.


management system







management.



















6.3: Planning of changes: b) the integrity of the

quality management system;


Control of changes


- 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


- 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



Decision Analysis and Resolution


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.


management system


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


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.


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.


- 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


- 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


- 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)


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. DAR, Page 1



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.




controls: e) any necessary actions are taken on

problems determined during the reviews, or

verification and validation activities;

SP1.4 Select evaluation methods.



planning











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.












management system


alternatives are explored during the Analysis

phase of the Portfolio Kanban, Value Stream

Kanban, and Program Kanban.


- 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)


- 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.


- 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.





SP1.6 Select solutions from alternatives based on evaluation criteria.


management system











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.


- 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



Integrated Project Management


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.



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.


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.


measuring resources: 7.1.5.1: General

Story Points estimate the value and effort for

each requirement.


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.





per Iteration.

SP1.3Establish and maintain the project’s work environment based on

the organization's work environment standards.


- 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.


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. IPM, Page 1



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.


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.


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 Iteration Backlog shows all of the user

stories committed to the Iteration and related

tasks.



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














Enablers.



controls









- 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.


- 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.


- None

Artifact Example:

- Requirement list for the integrated work environment that enables collaboration

of relevant stakeholders

- Periodic evaluation sheet of the integrated work environment









the work.



completed.




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.




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.



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


The Daily Stand-up Meeting coordinates

development team members and establishes

the day’s priorities.





- 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.


- 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.


- None

Artifact Example:

- Documented shared vision

- List of team members assigned to each integrated team

- Integrated team charters

- Periodic integrated team status reports







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



SP2.2Participate with relevant stakeholders to identify, negotiate, and

track critical dependencies.





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.




team.



changes

The Daily Stand-up Meeting addresses

completed tasks, tasks that will be done, and

any impediments.



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.


- 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.









team.




team.


- 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:


- 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


- Issues and dispositions for resolving stakeholder interfaces and

misunderstanding.


- 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.


- 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


- Defects, issues, and action items arising from stakeholder reviews


- Projects defined process for identifying, negotiating, and tracking critical

dependencies


- Stakeholder milestone/project status reviews

- Updated project plans reflecting and associated artifacts demonstrating

negotiating and tracking.



Measurement and Analysis


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.


them: 6.2.1: b) be measurable;


determine their information needs and


collecting that information based on Agile

practices.


determine their information needs and


collecting that information based on SAFe®

practices.



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;







9.1: Monitoring, measurement, analysis and

evaluation: 9.1.1: General: a) what needs to be

monitored and measured;


evaluation: 9.1.3: Analysis and evaluation

SP1.2 Specify measures to address measurement objectives.










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.








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.












- · 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.


- 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).


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. MA, Page 1



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.


- · 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.







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 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.


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.


- (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.


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.




their status;


each requirement. The development team

estimates User Stories (or Themes, Features,

etc.) with assistance from the Product Owner.


each requirement. The development team

estimates User Stories (or Themes, Features,

etc.) with assistance from the Product Owner.


evaluation: 9.1.3: Analysis and evaluation: c) the

performance and effectiveness of the quality

management system;


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 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.




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.


- 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)


(briefings, minutes, action items, etc.)

- Follow-up analyses performed to address areas of concern, if necessary

- Revisions of criteria for future analysis.


- (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.


- 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.








management system;


results of the sprint using the Burndown Chart to

compare the amount of work planned with the

amount of work actually completed.


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.




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).




management system;

SP2.4Communicate results of measurement and analysis activities to all

relevant stakeholders.




their status;



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.




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.


results of the sprint using the Burndown Chart to

compare the amount of work planned with the

amount of work actually completed.


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.


- 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)


(briefings, minutes, action items, etc.)

- Follow-up analyses performed to address areas of concern, if necessary

- Revisions of criteria for future analysis.


- 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


- 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.



Organizational Process Definition


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.


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.





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.


- 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


- 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.


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPD, Page 1





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.


- 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.


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;


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.


- 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





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.



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.


- 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.






- 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




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 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.


- None

Artifact Example:

Rules and guidelines for structuring and forming integrated teams





process; f) the need to control interfaces

between persons involved in the design and



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.



Organizational Process Focus


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.


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;







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.


them: 6.2.1: a) be consistent with the quality

policy;


them: 6.2.2: a) what will be done;




10.1: General

SP1.2Appraise the organization's processes periodically and as needed

to maintain an understanding of their strengths and weaknesses.


context









Iteration.


processes: 4.4.1: f) address the risks and

opportunities as determined in accordance with

the requirements of 6.1;


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 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


- 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)


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPF, Page 1




6.1.1


10.1: General

SP1.3Identify improvements to the organization's processes and

process assets.


processes







well and what did not go well in the last Iteration,


Iteration.







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.1

6.3: Planning of changes: a) the purpose of the

changes and their potential consequences;



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.


processes





Iteration.







maintained.











- 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


- 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)


- 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






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;






10.1: General

SP2.2 Implement process action plans.


processes: 4.4.1





Iteration.







maintained.


processes means that action items

implemented from the Sprint Retrospective

meeting should be evaluated for their effect on

process performance.













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.


processes: 4.4.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.



- 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


- 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


- 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.






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.


processes: 4.4.1








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.




















10.1: General

SP3.3Monitor the implementation of the organization's set of standard

processes and use of process assets on all projects.


context







processes: 4.4.1













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


assets


assets




- Records of training or orientation provided on the new process assets




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


assets


assets








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


assets


assets












the organization's business processes; g)

ensuring that the quality management system

achieves its intended results;


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.


processes: 4.4.1





Iteration.


General: i) promoting improvement;












opportunities; b) how to : 2) evaluate the

effectiveness of these actions;


them: 6.2.1: g) be updated as appropriate;







10.1: General


10.2.1: f) make changes to the quality

management system, if necessary.





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


assets


assets






- 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



Organizational Performance Management


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.


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.”


Customer focus: c) the focus on enhancing

customer satisfaction is maintained.


a) is appropriate to the purpose and context of

the organization and supports its strategic

direction; b) provides a framework for setting

quality objectives;



10.1: General: a) improving products and

services to meet requirements as well as to

address future needs and expectations;


SP1.2Analyze process performance data to determine the organization's

ability to meet identified business objectives.


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.





top management;







SP1.3Identify potential areas for improvement that could contribute to

meeting business objectives.


- 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


- None

Artifact Example:

- Analysis of current capability vs. business objectives

- Process performance shortfalls

- Risks associated with meeting business needs and objectives


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPM, Page 1




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.


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.







maintained.


d) includes a commitment to continual

improvement of the quality management

system.





top management;





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.


processes: h) improve the processes and the

quality management system.




Iteration.


- None

Artifact Example:

- Potential areas for improvement


- 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


















SP2.2

Analyze suggested improvements for their possible impact on

achieving the organization's quality and process performance

objectives.







Iteration.
















SP2.3 Validate selected improvements.


processes: 4.4.1: h) improve the processes and




Iteration.














SP2.4

Select and implement improvements for deployment throughout

the organization based on an evaluation of costs, benefits, and

other factors.






Iteration.


- 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


- 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


- 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


- 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


- 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





6.3: Planning of changes.














10.2.2: b) the results of any corrective action.


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.






Iteration.







maintained.














SP3.2 Manage the deployment of selected improvements.






Iteration.







maintained.











- 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


- 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


- 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









SP3.3

Evaluate the effects of deployed improvements on quality and

process performance using statistical and other quantitative

techniques.




Iteration Retrospective meeting minutes or

action items may be an output from the meeting.















- 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


- 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



Organizational Process Performance


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.


context


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.


General: b) ensuring the integration of the


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.







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





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.






to create their Program Performance Metrics,







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.


- The organization goals should be established that represent the quantitative

objectives for the organization

Artifact Example:


- 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


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPP, Page 1

Organizational Process Performance


SP1.3Establish and maintain definitions of the measures to be included

in the organization's process performance analyses.

















evaluation: 9.1.1: General: b) the methods for



SP1.4Analyze the performance of the selected processes, and establish

and maintain the process performance baselines.


evaluation: 9.1.1: General: d) when the results

from monitoring and measurement shall be



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.



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.




management system;


- 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


- 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


- 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


- Procedures on Organization metrics, Process analysis and/or Internal Quality

Audits

- Established Process Performance and Baseline Models

- Meeting minutes from process performance reviews


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OPP, Page 2

Organizational Training


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;


determine their strategic training needs and


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.


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. OT, Page 1




- 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


planning: c) the required design and

development verification and validation

activities; d) the responsibilities and authorities


process;


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.


Control of production and service provision: e)

the appointment of competent persons,

including any required qualifications;


determine their tactical training needs and


maintaining tactical training needs based on

Agile practices.

The organization at all levels of SAFe® must

determine their tactical training needs and


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


a SAFe® Program Consultant (SPC), who may

be an employee or an outside consultant.


- 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.


- 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





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.





The Iteration Retrospective may evaluate the

effectiveness of training received by the

members of an Agile team in relation to the

Iteration.


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.


- 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


- 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


- 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



Project Monitoring and Control


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


estimated schedule.

Agile project management tools are used to

track the status of stories, defects, test cases,

estimates, actuals, burndowns, and more.


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)


evaluation: 9.1.3: Analysis and evaluation: d)

if planning has been implemented effectively;







SP1.3 Monitor risks against those identified in the work plan.


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.


- 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.


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PMC, Page 1




determining, maintaining, and retaining


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.





Integration/Continuous Build imply the use of

a code repository for configuration

management.


Continuous Integration/Continuous Build

imply the use of a code repository for

configuration management.


and maintaining the Product Backlog by

adding and prioritizing User Stories.




SP1.5 Monitor stakeholder involvement against the plan.

8.7: Control of nonconforming outputs: 8.7.1:

c) informing the customer;








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.


achieve them: 6.2.1: e) be monitored;

The Sprint Burndown Chart shows the status

of the work that the development team has


estimated schedule.





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;



any impediments.



any impediments.


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.




SP1.7 Review accomplishments and results at selected milestones.


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.


- 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


- 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)


- 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).


- 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






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;


evaluation: 9.1.1: General: c) when the

monitoring and measuring shall be

performed; d) when the results from

monitoring and measurement shall be





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.


b) segregation, containment, return or

suspension of provision of products and

services;


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.


evaluation: 9.1.2: Customer satisfaction





10.1: General



applicable: 1) take action to control and

correct it;


- 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.


- 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






10.2.2: a) the nature of the nonconformities

and any subsequent actions taken;

SP2.2 Take corrective action on identified issues.






Sprint Retrospective meeting minutes or

action items may be an output from the

meeting.



Iteration.


8.2.1: Customer satisfaction: c) obtaining

customer feedback relating to products and

services, including customer complaints;


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.




services;


c) describes any concessions obtained;







10.1: General




correct it;




SP2.3 Manage corrective actions to closure.






The Sprint Retrospective meeting may


sprint.



Iteration.


- 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.


- None

Artifact Example:

- Corrective action results

- Review and meeting minutes associated with corrective actions

- Corrective action effectiveness analysis

- Closed corrective action requests


- 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.








services;


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




correct it;








- None

Artifact Example:

- Corrective action results

- Review and meeting minutes associated with corrective actions

- Corrective action effectiveness analysis

- Closed corrective action requests



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.







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.



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;


each requirement.


each Story.



controls: a) the results to be achieved are

defined;





per sprint.





per sprint.

SP1.3 Define lifecycle phases on which to scope the planning effort.


- 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.


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PP, Page 1

Project Planning


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)







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.


each requirement.


each Story.





per sprint.





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.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.




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 work.


- 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)


- 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)



Project Planning




completed.




SP2.2 Identify and analyze risks.


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.



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.


determining, maintaining, and retaining


necessary:







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.







- 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.


- 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.


- 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.


- 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)



Project Planning






SP2.5 Plan for knowledge and skills needed to perform the work.





process;

Training employees in Agile practices and


an Agile Coach/Mentor, who may be an

employee or an outside consultant.

Training employees in SAFe® practices and


a SAFe® Program Consultant (SPC), who may

be an employee or an outside consultant.






SP2.6 Plan the involvement of identified stakeholders.


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.





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.



planning












Enablers.












the work.


- The needed knowledge and skills in this SP should be compared with those

provided by the work staff as determined in PP SP2.4



Artifact Example:

- Inventory of skill needs

- Staffing and new hire plans

- Databases (e.g. skills, training)

- Training plans

- Databases (e.g., skills and training)


- 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


- 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)


- 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



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.



Project Planning




completed.




SG3Commitments to the work plan are established and

maintained.

SP3.1Review all plans that affect the work to understand project

commitments.



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.



Sprint Planning is performed together by the

Product Owner, Scrum Master, and the

development team.

Iteration Planning is performed together by the


development team.







SP3.2Adjust the work plan to reconcile available and estimated

resources.


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.




Iteration.


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.



changes: a) design and development changes;

SP3.3Obtain commitment from relevant stakeholders responsible for

performing and supporting plan execution.


8.2.1: Customer communication: a) providing

information relating to products and services;







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.


- 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


- 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



- 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


- 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.


- 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


- Issues and conflicts identified across subordinate plans

- IMP, IMS, SEMP, SDP (see model)



Project Planning


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)



development team.



development team, and Iteration Goals are

collaboratively developed.






- 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 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.



Process and Product Quality Assurance


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.


context









Iteration.


management system c) the products and

services of the organization.











processes: 4.4.1


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;




necessary: 2) to demonstrate the conformity of

products and services to their requirements.








external providers: b) the approval of: 2)

methods, processes and equipment;

8.6: Release of products and services



criteria;




evaluation: 9.1.3: Analysis and evaluation: b) the

degree of customer satisfaction;


- “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)


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PPQA, Page 1






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


completed User Stories meet the Definition of






management system c) the products and

services of the organization.




necessary: 2) to demonstrate the conformity of

products and services to their requirements.








external providers: b) the approval of: 1)



Post-delivery activities




criteria;


evaluation: 9.1.3: Analysis and evaluation: a)

conformity of products and services;





- Refer to the Project Planning PA for more information about identifying processes

to be objectively evaluated


areas


plan. Look for evaluations performed throughout the lifecycle, not just at the end a

project or in close proximity to the assessment



another plan




Artifact Example:

- Audit reports



- Quality assurance plan, identifying the processes subject to evaluation, and

procedures for performing evaluations

- Applicable process descriptions, standards, and procedures


- Criteria and checklists used for work product / service evaluations (e.g. what,

when, how, who)

- Schedule for performing process evaluations (planned, actual) at selected



of the QA function



signature)


- Look for in-progress or incremental evaluations of work products and services,

and at selected milestones




- Refer to the Project Planning PA for more information about identifying work

products to be objectively evaluated.


areas


plan. Look for evaluations performed throughout the lifecycle, not just at the end of

the project or in close proximity to the assessment



another plan




Artifact Example:

- Audit reports



- Quality assurance plan, identifying the work products and services subject to

evaluation, and procedures for performing evaluations


- 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



of the QA function



signature)








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;




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.


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;





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.













top management;



requirements.

7.4: Communication


organization shall control planned changes and

review the consequences of unintended

changes, taking action to mitigate any adverse

effects, as necessary.


- Look for in-progress or incremental evaluations of work products and services,

and at selected milestones




- Refer to the Project Planning PA for more information about identifying work

products to be objectively evaluated.


areas


plan. Look for evaluations performed throughout the lifecycle, not just at the end of

the project or in close proximity to the assessment



another plan




Artifact Example:

- Audit reports



- Quality assurance plan, identifying the work products and services subject to

evaluation, and procedures for performing evaluations


- 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



of the QA function



signature)


- 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


- 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.












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;




management system;


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;




system, including trends in: 4) nonconformities

and corrective actions; 5) monitoring and

measurement results;



applicable: 1) take action to control and correct

it; c) implement any action needed;

SP2.2 Establish and maintain records of quality assurance activities.


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.


generate action items or meeting minutes as an

output from the meeting.




activities is retained.8.6: Release of products and services: a)


criteria;


- 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


- 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.


- 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)


signature)

- Metrics or analyses used for quality assurance of processes and work products.Last updated 8/20/17





8.7: Control of nonconforming outputs: 8.7.1

8.7: Control of nonconforming outputs: 8.7.2: b)

describes the actions taken;




9:2: Internal audit: 9.2.2: f) retain documented

information as evidence of the implementation

of the audit programme and the audit results.



applicable: 1) take action to control and correct

it;


- 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)


signature)

- Metrics or analyses used for quality assurance of processes and work products.



Quantitative Project Management


SG1 Preparation for quantitative management is conducted.

SP1.1Establish and maintain the quality and process performance

objectives for the work.






organization;

The scrum team defines and agrees upon a

Definition of Done to use to determine that a

requirement has been completed.




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.








SP1.2

Using statistical and other quantitative techniques, compose a

defined process that enables the work to achieve its quality and

process performance objectives.



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.









- 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.


- Work Plan

- Minutes from metrics analysis meeting showing QPM planning and monitoring


- 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




- The measurement objectives for the project need to be defined.

Artifact Example:

- The quality and process-performance objectives for the work.

- Work Plan


- Organizational business, quality and process-performance objectives

- Procedures on project planning and/or metrics


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. QPM, Page 1










SP1.4Select measures and analytic techniques to be used in quantitative

management.






estimated schedule.





per sprint.






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)).








SG2 The work is quantitatively managed.

SP2.1Monitor the performance of selected subprocesses using

statistical and other quantitative techniques.



monitored and measured; b) the methods for







performance.



conformity of products and services; c) the


management system; g) the need for

improvements to the quality management

system.





per sprint.


- 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



- Minutes from metrics analysis meeting showing QPM monitoring


- 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


- 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















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.



monitored and measured; b) the methods for






estimated schedule.




estimated schedule.



conformity of products and services; c) the


management system; g) the need for

improvements to the quality management

system.


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.












performance.




Iteration.


Adapt workshop, the teams hold a Problem-

Solving and Retrospective workshop to identify

a small number of significant problems that

teams decide to address.


- 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



- Minutes from metrics analysis meeting showing QPM monitoring


- None

Artifact Examples:

- Predictions of outcomes to be achieved relative to the quality and process-


- 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


- 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



Requirements Management


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.




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.




level objectives.


them: 6.2.1: c) take into account applicable

requirements;


identifies and groups requirements for the

product and defines high-level estimates for

effort, priority, and time frames.






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;





to the end user.





respectively.


Identification and traceability

SP1.2 Obtain commitment to requirements from participants.




requirements of this International Standard;







level objectives.

The Product Roadmap / Product Backlog may

be created with input from stakeholders and the

development team.




each Story.



development team.



development team.

SP1.3 Manage changes to requirements as they evolve.



and services: 8.2.4:Changes to requirements for

products and services



added or changed.










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.



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


- 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


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. REQM, Page 1

Requirements Management


8.7: Control of nonconforming outputs: 8.7.1





of the card.







achieved;




estimated schedule.






SP1.5Ensure that plans and work products remain aligned with

requirements.


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.



and services: 8.2.4:Changes to requirements for

products and services




estimated schedule.

















- 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


-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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. REQM, Page 2

Risk Management


SG1 Preparation for risk management is conducted.SP1.1 Determine risk sources and categories.





satisfaction are determined and addressed;





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.


context




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.


General: d) promoting the use of the process

approach and risk-based thinking;











monitor risks.


- 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).


- 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


- “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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RSKM, Page 1

Risk 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.








monitor risks.





SP2.2Evaluate and categorize each identified risk using defined risk

categories and parameters, and determine its relative priority.











monitor risks.






- 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


- 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)


- “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.)



Risk Management


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.











opportunities;



monitor risks.


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).




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.








monitor risks.



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.


- 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.


- 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



Supplier Agreement Management


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.


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.



providers

SP1.2Select suppliers based on an evaluation of their ability to meet the

specified requirements and established criteria.


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.


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;






- 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


- “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)


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. SAM, Page 1




evaluation: 9.1.3: Analysis and evaluation: f) the

performance of external providers;




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.



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®.


- 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


- “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.






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.



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.



external providers

SP2.2Ensure that the supplier agreement is satisfied before accepting

the acquired product.


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.



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.


- 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.)


- 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







external providers: a) the processes, products

and services to be provided; b) the approval of:

1) products and services; 2) methods,

processes and equipment;


evaluation: 9.1.3: Analysis and evaluation: f) the

performance of external providers;

SP2.3 Ensure the transition of products acquired from the supplier.



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.



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.


- 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


- 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



Requirements Development


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.










level objectives.







added or changed.





authorities: d) ensuring the promotion of

customer focus throughout the organization;




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.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;







achieved;

SP1.2Transform stakeholder needs, expectations, constraints and

interfaces into prioritized customer requirements.



User Stories are created based on identified

stakeholders, including users (who are captured

as personas in the user stories).







product and defines high-level estimates for

effort, priority, and time frames.



(Pis) and the next planned Pis, with upcoming


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.



and services;


- 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


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. RD, Page 1





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;



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.








frames.



(Pis) and the next planned Pis, with upcoming



c) includes a commitment to satisfy applicable

requirements;


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,


respectively.



and services;



outputs: a) meet the input requirements

SP2.2 Allocate the requirements for each product component.





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).





to the end user.





respectively.


- 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


- 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


- None

Artifact Examples:


- Product requirements

- Product component requirements

- Results of methods (e.g., House of quality) used to translate customer needs into

technical parameters


- Revision histories of requirements

- Analysis of cost performance tradeoffs of requirements and of lifecycle phases

considering business objectives

- Performance modeling results





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.




SP2.3 Identify interface requirements.


- None

Artifact Examples:

- Interface requirements

- Architecture documents

- Integration test plans


- Architecture documents

- Integration test plans







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.



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.



and services: 8.2.3.1:c) requirements specified

by the organization;








level objectives.



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.



and services: 8.2.3.1:e) contract or order

requirements differing from those previously

expressed.











defined;


- None

Artifact Examples:

- Operational concept

- Product installation, maintenance and support concepts

- Disposal concepts

- Scenarios (e.g., Use cases, Timeline scenarios

- Revision histories

- New requirements


- None

Artifact Examples:

- Requirement allocation sheets

- Provisional requirement allocations


- Relationships between derived requirements

- Specifications

- Design constraints

- Indication of allocated requirements traceability

- Include allocation of product performance, design constraints, and fit, form, and

function






Control of production andd service provision: a)





achieved;

SP3.2Establish and maintain a definition of required functionality and

quality attributes.


them: 6.2.1: c) take into account applicable

requirements; d) be relevant to conformity of





product.



Increment (Pis) and the next planned Pis, with









Enablers.





services;



the work.





expressed.


Themes and Features in the Product Roadmap /

Product Backlog.





respectively.


















Definition of Done.



a) functional and performance requirements;







defined;



outputs: The organization shall retain

documented information on design and

development outputs.


- None

Artifact Examples:

- Operational concept

- Product installation, maintenance and support concepts

- Disposal concepts

- Scenarios (e.g., Use cases, Timeline scenarios

- Revision histories

- New requirements


- 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











achieved;


Preservation

SP3.3Analyze requirements to ensure that they are necessary and

sufficient.















services;

The Review and Analysis phases of the

Portfolio, Value Stream, and Program Kanbans

evaluate and elaborate ideas captured from the

Funnel phase.





expressed.










a) functional and performance requirements;



c) statutory and regulatory requirements;



e) potential consequences of failure due to the

nature of the products and services.



external providers


- None

Artifact Examples:

- Requirements defects reports

- Key requirements

- Proposed requirements changes to resolve defects

- Technical performance measures


- 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











achieved;

SP3.4Analyze requirements to balance stakeholder needs and

constraints.



The Review and Analysis phases of the

Portfolio, Value Stream, and Program Kanbans

evaluate and elaborate ideas captured from the

Funnel phase.











products and services: b) the organization can

meet the claims for the products and services it

offers.









services;





expressed.










d) standards or codes of practice that the

organization has committed to implement;


- 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


- None

Artifact Examples:

- Requirements defects reports

- Key requirements

- Proposed requirements changes to resolve defects

- Technical performance measures











achieved;






SP3.5Validate requirements to ensure the resulting product will perform

as intended in the end user's environment.












them: 6.2.1: d) be relevant to conformity of







of the card.














services;





expressed.












development to meet requirements;



outputs: b) are adequate for the subsequent

processes for the provision of products and

services;


- 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



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 specification§ Requirements changes

- Results of techniques to demonstrate requirements functionality (e.g.,

prototypes, simulations, analyses, scenarios, and story boards)







outputs: d) specify the characteristics of the

products and services that are essential for their

intended purpose and their SAFe® and proper

provision.



control: d) determine the verification, or other

activities, necessary to ensure that the externally

provided processes, products and services meet

requirements.







achieved;

8.5:Production and service provision: 8.5.5: Post-

delivery activities



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 specification§ Requirements changes

- Results of techniques to demonstrate requirements functionality (e.g.,

prototypes, simulations, analyses, scenarios, and story boards)



Technical Solution


SG1Product or product component solutions are selected

from alternative solutions.SP1.1 Develop alternative solutions and selection criteria.




of the design and development activities;



team at any stage of scrum. Records of









alternatives are added into the Funnel phase of

the Portfolio Kanban, Value Stream Kanban,

and Program Kanban as Epics, Capabilities, or

Features, respectively.








a trade-off curve.





others.

SP1.2Select the product component solutions based on selection

criteria.




of the design and development activities;












alternatives are explored during the Analysis

phase of the Portfolio Kanban, Value Stream

Kanban, and Program Kanban.









- 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


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. TS, Page 1

Technical Solution









a trade-off curve.





others.

SG2 Product or product component designs are developed.

SP2.1 Develop a design for the product or product component.













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.















SP2.2 Establish and maintain a technical data package.



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.


- 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


- 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.)


- 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


- “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)



Technical Solution














standards.

SP2.3 Design product component interfaces using established criteria.



Development is performed during a sprint based

on the user stories in the sprint backlog to

create shippable functionality.











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.






















implementation







design level

Artifact Examples:



implementation













etc.)








implementation







design level

Artifact Examples:



implementation













etc.)



Technical Solution


SP2.4Evaluate whether the product components should be developed,

purchased, or reused based on established criteria.

7.1: Resources: 7.1.1: General.













SG3Product components, and associated support

documentation, are implemented from their designs.SP3.1 Implement the designs of the product components.



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.



planning: j) the documented information needed

to demonstrate that design and development

requirements have been met;





to the end user.





respectively.








SP3.2 Develop and maintain the end-use documentation.


- “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.


- 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



Technical Solution




planning: j) the documented information needed

to demonstrate that design and development

requirements have been met;

User Documentation is created during the

Release Sprint.






8.5.4: Preservation


- “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.



Product Integration


SG1 Preparation for product integration is conducted.SP1.1 Establish and maintain a product integration strategy.



















SP1.2Establish and maintain the environment needed to support the

integration of the product components.


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.













SP1.3Establish and maintain procedures and criteria for integration of

the product components.


establishing criteria for: 1) the processes





of the card.



















SG2The product component interfaces, both internal and

external, are compatible.

SP2.1 Review interface descriptions for coverage and completeness.


- 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


- 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)


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. PI, Page 1

Product Integration



- “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



Inputs shall be adequate for design and

development purposes, complete and

unambiguous.





of the card.






SP2.2Manage internal and external interface definitions, designs, and

changes for products and product components.



Conflicting design and development inputs shall

be resolved.











Definition of Done.



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.





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.


- 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



Product Integration




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;





of the card.








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.


Story in order to complete it.

SP3.2Assemble product components according to the product

integration strategy and procedures.





development to meet requirements

















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.



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;












- “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


- “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


- 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



- 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



Product Integration


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


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.


- “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.



- Regression testing procedures and results



Verification


SG1 Preparation for verification is conducted.

SP1.1Select work products to be verified and verification methods to be

used.





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.










SP1.2Establish and maintain the environment needed to support

verification.


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.





outputs meet the input requirements;


- 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.


- 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.


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VER, Page 1

Verification



establishing criteria for: 2) the acceptance of


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.


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;





SG2 Peer Reviews are performed on selected work products.

SP2.1 Prepare for peer reviews of selected work products.






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 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.










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.


- “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


- 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


- 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 procedures

- Expected results and tolerances identified

- Equipment and environmental components identified



Verification






completed User Stories meet the Definition of







external providers









Iteration.

SG3Selected work products are verified against their

specified requirements.SP3.1 Perform verification on selected work products.






















activities, necessary to ensure that the

externally provided processes, products and

services meet requirements.








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.


Preservation


SP3.2 Analyze results of all verification activities.


context












- 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.


- 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.


- 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



Validation


SG1 Preparation for validation is conducted.

SP1.1Select products and product components to be validated and

validation methods to be used.




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.



and services: 8.2.3.1: a) requirements specified

by the customer, including the requirements for

delivery and post-delivery activities;



and services: 8.2.3.1: b) requirements not stated

by the customer, but necessary for the specified

or intended use, when known;









activities;



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.





















planning: g) the need for involvement of

customers and users in the design and



- 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


- 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


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. VAL, Page 1

Validation


SP1.3 Establish and maintain procedures and criteria for validation.















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.


authorities: b) ensuring that the processes are

delivering their intended outputs;































activities, necessary to ensure that the externally

provided processes, products and services meet

requirements.


- 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.


- 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



Validation




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.




New User Stories may be generated from the

Sprint Review.

New Stories may be generated from the Team

Demo/System Demo.







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.


- 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.


- As-run procedures log.

- Validation cross-reference matrix.

- Operational demonstrations.

- Documented validation environment

- Data collected from performing validation procedures

- List of deviations encountered.


- The validation data results are compared against the evaluation criteria

established in SP1.3

Artifact Examples:

- Validation deficiency reports

- Validation issues.

- Analysis reports


- Procedure change request.

- Validation evaluation criteria

- Comparison of actual vs. expected results (e.g., measurements and performance

data)




GG2 The process is institutionalized as a managed process.

GP2.1Establish and maintain an organizational policy for planning and

performing the process.


GP2.2 Establish and maintain the plan for performing the process.


them: 6.2.2



- “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).


- 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.


policy

Generic Practices (All Process Areas)


Download the latest version of this crosswalk at www.excellenceinmeasurement.com. Generic Practices, Page 1



GP2.3

Provide adequate resources for performing the process,

developing the work products, and providing the services of the

process.


processes: 4.4.1: d) determine the resources

needed for these processes and ensure their

availability;


General: e) ensuring that the resources needed

for the quality management are available;


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





- “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).








- 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]





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.


processes: 4.4.1: e) assign the responsibilities

and authorities for these processes;

5.3: Organizational roles, responsibilities and

authorities


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.


policy: b) be communicated, understood and

applied within the organization;

7.1: Resources: 7.1.6: Organizational

knowledge

7.2: Competence


- 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).


- 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]


- “…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





GP2.6Place selected work products of the process under appropriate

levels of control.

7.5: Documented information: 7.5.1: General


and updating




- 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.


- 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)


- 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





GP2.7Identify and involve the relevant stakeholders of the process as

planned.




8.2.1: Customer communication

8.2.4: Changes to requirements for products

and services



planning: g) the need for involvement of

customers and users in the design and



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.


- 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


• Communicating bidirectional traceability


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.


- 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


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.


- 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)



and services: 8.2.4: Changes to requirements

for products and services





GP2.8Monitor and control the process against the plan for performing

the process and take appropriate corrective action.


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;





them: 6.2.1: e) be monitored;





traceability





- 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


• Communicating the bidirectional traceability


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


• Communicating bidirectional traceability


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;


- "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:


• 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.






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.


processes: 4.4.1: g) evaluate these processes

and implement any changes needed to ensure

that these processes achieve their intended

results;






organization; g) ensuring that the quality

management system achieves its intended

results;




requirements of this International Standard; e)

ensuring that the integrity of the quality

management system is maintained when




them: 6.2.1: a) be consistent with the quality

policy;


changes and their potential consequences; b)

the integrity of the quality management system;





9.2: Internal audit: 9.2.1


- "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:


Elaboration: Examples of measures and work products used in monitoring and

controlling include the following:


• 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).




project plans

- Impact assessments for requirements changes


- "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


requirements

- Examples of work products reviewed include the following:

• Requirements


- "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:



requirements

Examples of work products reviewed include the following:

• Requirements


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.




project plans






9.2: Internal audit: 9.2.2

GP2.10Review the activities, status, and results of the process with higher

level management and resolve issues.





top management;




8.7: Control of nonconforming outputs: 8.7.1: d)

obtaining authorization for acceptance under

concession.

9.3: Management review: 9.3.1: General


review inputs


review outputs

GG3 The process is institutionalized as a defined process.

GP3.1 Establish and maintain the description of a defined process.


processes: 4.4.1



- “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.


- "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.


- "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:



requirements

- Examples of work products reviewed include the following:

• Requirements


- "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:



requirements

Examples of work products reviewed include the following:

• Requirements


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.




project plans











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.


review inputs: f) opportunities for improvement


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.


- “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.


- “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:


• 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


- 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







- “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:


• 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


- 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



Documents

The EMT CMMI /ISO 9001/Agile/SAFe Crosswalk · Excellence in Measurement Technology presents: The EMT CMMI®/ISO 9001/Agile/SAFe® Crosswalk How to use this crosswalk: This crosswalk