ISO/IEC TS 20000-15:2024

Information technology - Service management - Part 15: Guidance on the application of Agile and DevOps principles in a service management system

This document provides guidance on the relationship between ISO/IEC 20000–1:2018 and two commonly used frameworks, Agile and DevOps. It can be used by any organization or person wishing to understand how Agile and DevOps can be used with ISO/IEC 20000–1, including: a) an organization that has demonstrated or intends to demonstrate conformity to the requirements specified in ISO/IEC 20000–1 and is seeking guidance on the use of Agile or DevOps to establish or improve the SMS and the services; b) an organization that already uses Agile or DevOps and is seeking guidance on how Agile or DevOps can be used to support efforts to demonstrate conformity to the requirements specified in ISO/IEC 20000–1; c) an assessor or auditor who wishes to understand the use of Agile or DevOps as a support for achieving the requirements specified in ISO/IEC 20000–1. Both approaches can be used independently or together. Depending on the context, an organization can deploy Agile frameworks only, DevOps frameworks only, use both Agile and DevOps frameworks in isolation, or use an integrated workflow with combined Agile and DevOps approaches. In any of these situations, this document can be used as guidance for the integration of Agile and DevOps practices in an SMS. The guidance in this document can assist an organization in planning and preparing for a conformity assessment against ISO/IEC 20000-1, noting that an organization can only claim conformity by fulfilling all requirements specified in ISO/IEC 20000-1.

Technologies de l'information – Gestion des services — Partie 15: Lignes directrices pour l'application des principes "Agile" et "DevOp"s dans un système de gestion des services

General Information

• Status: Published
• Publication Date: 14-May-2024
• ICS: 03.080.99 - Other services
• ICS: 35.020 - Information technology (IT) in general
• Technical Committee: ISO/IEC JTC 1/SC 40 - IT service management and IT governance
• Drafting Committee: ISO/IEC JTC 1/SC 40 - IT service management and IT governance
• Current Stage: 6060 - International Standard published
• Start Date: 15-May-2024
• Due Date: 04-Oct-2024
• Completion Date: 15-May-2024

Overview - ISO/IEC TS 20000-15:2024 (Agile & DevOps guidance)

ISO/IEC TS 20000-15:2024 is a Technical Specification from ISO that provides guidance on applying Agile and DevOps principles within a Service Management System (SMS) based on ISO/IEC 20000-1:2018. It explains how Agile and DevOps - independently or together - can support planning, implementing and continually improving services while helping organizations prepare for conformity assessment against ISO/IEC 20000-1. The document is aimed at organizations, teams and assessors who need practical alignment between service management and modern delivery practices.

Key topics and technical focus

The specification covers practical, technical topics that map Agile and DevOps concepts to SMS requirements, including:

• Agile principles: Agile Manifesto, iterative and incremental delivery, customer collaboration, defining objectives, handling high-uncertainty work, servant leadership and Agile teams in a service context.
• DevOps principles: customer-centric action, end-to-end responsibility, cross-functional autonomous teams, automation, “shift-left” practices and “continuous everything” (continuous integration, delivery, deployment).
• Service management interfaces: change management, release and deployment management, operational change controls and the role of documented information in an SMS.
• Quality and improvement: continuous improvement cycles, metrics and measurement, competence and Agile culture to meet service objectives.
• Patterns and anti-patterns: practical examples of successful and problematic ways to combine Agile/DevOps with ISO/IEC 20000–1.
• Correlation: Annex A provides a summary correlation of ISO/IEC 20000-1 clauses to Agile and DevOps concepts to support auditability and compliance planning.

Practical applications - who should use this standard

This guidance is valuable for:

• IT organizations implementing or improving an SMS that want to adopt Agile and/or DevOps practices while remaining aligned to ISO/IEC 20000-1.
• Teams already using Agile/DevOps seeking to demonstrate how those practices support service management requirements and conformity.
• Assessors and auditors who need to understand how Agile and DevOps can act as evidence or enablers for ISO/IEC 20000-1 requirements. Practical uses include designing release and deployment pipelines that satisfy change controls, defining metrics for continual improvement, and aligning team structures and automation with service requirements.

Related standards

• ISO/IEC 20000-1:2018 - Service management system requirements
• ISO/IEC/IEEE 32675 - DevOps principles for reliable and secure systems
• ISO/IEC 33202 - Core Agile practices

By mapping Agile and DevOps to established SMS requirements, ISO/IEC TS 20000-15:2024 helps organizations modernize service delivery while maintaining conformity and audit readiness.

Standards Content (Sample)

Technical
Specification
ISO/IEC TS
20000-15
First edition
Information technology — Service
2024-05
management —
Part 15:
Guidance on the application of Agile
and DevOps principles in a service
management system
Technologies de l'information – Gestion des services —
Partie 15: Lignes directrices pour l'application des principes
"Agile" et "DevOp"s dans un système de gestion des services
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Introduction to ISO/IEC 20000–1:2018 . 4
5 Agile within an SMS based on ISO/IEC 20000–1 . 6
5.1 Background of Agile .6
5.2 Agile Principles .6
5.2.1 Overview .6
5.2.2 Agile Manifesto .6
5.2.3 List of Agile Principles .7
5.3 Agile and services .7
5.3.1 Value in a service environment .7
5.3.2 Value, customers and uncertainty in services .8
5.4 Defining objectives .9
5.5 High-uncertainty contracts . .10
5.6 How to achieve the service objectives .11
5.7 Agile learning . . .11
5.8 The Agile team in a service context . 12
5.8.1 Customer collaboration . 12
5.8.2 Servant leadership . 13
5.8.3 Continuous improvement . 13
5.8.4 Competence .14
5.8.5 Agile culture .14
5.9 Metrics .14
5.10 Change management . 15
5.10.1 Change and the SMS. 15
5.10.2 Operational change management and release and deployment management . 15
5.11 Simplicity and efficiency .16
5.12 The role of documented information .16
5.13 Compatibility of Agile with service management .17
6 DevOps within an SMS based on ISO/IEC 20000-1 . 17
6.1 General .17
6.2 DevOps principles .18
6.3 Customer-centric action .19
6.4 Create with the end in mind .19
6.5 End-to-end responsibility .19
6.6 Cross-functional autonomous teams . 20
6.7 Continuous improvement . 20
6.8 Automate everything . 20
6.9 Shift-left and continuous everything .21
6.9.1 Shift-left .21
6.9.2 Continuous everything .21
6.10 Compatibility of DevOps with service management . 22
7 Applying Agile and DevOps within an SMS .23
7.1 Benefits of applying Agile in an SMS . 23
7.2 Benefits of applying DevOps in an SMS . 25
7.3 Patterns and anti-patterns of applying Agile in an SMS . 26
7.4 Patterns and anti-patterns of applying DevOps in an SMS . 28
7.5 Using Agile and DevOps together . 28

© ISO/IEC 2024 – All rights reserved
iii
Annex A (informative) Summary correlation of ISO/IEC 20000-1:2018 clauses to Agile and
DevOps concepts .30
Bibliography .34

© ISO/IEC 2024 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 40, IT Service Management and IT Governance.
A list of all parts in the ISO/IEC 20000 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
v
Introduction
This document is intended to assist users in relating the requirements specified in ISO/IEC 20000–1:2018
to the principles and practices of two frequently used software and service development frameworks, Agile
and DevOps. Organizations can refer to this guidance as a cross-reference between the frameworks to help
them plan, implement and improve a service management system (SMS).
ISO/IEC 20000–1 is the International Standard for service management and specifies requirements which
can be used as the basis of a conformity assessment.
ISO/IEC 20000–1 specifies an integrated process approach in which an organization establishes, implements,
maintains and continually improves an SMS. The services can be delivered to internal or external customers
or a combination of both. Other parts of the ISO/IEC 20000 series provide supporting guidance.
Agile is defined as a collection of frameworks and techniques focusing on collaboration, iterative and
incremental development and continuous improvement.
DevOps is defined as a set of principles and practices which enable better communication and collaboration
between relevant stakeholders for the purpose of specifying, developing and operating software and
systems services, and continuous improvements in all aspects of the lifecycle (ISO/IEC/IEEE 32675).
Despite these definitions being focused on software development, both Agile and DevOps principles have
also been used in a much broader sense, including the development and delivery of services.
The DevOps framework is based on the Agile framework, adding automation of service development and
delivery to it. Many Agile concepts discussed in this document are therefore equally applicable to DevOps.
Organizations can implement and improve their SMS using the requirements specified in ISO/IEC 20000–
1 and the guidance in the other parts of the ISO/IEC 20000 series. An organization can adopt Agile and
DevOps practices to support the management of their services in alignment with the requirements specified
in ISO/IEC 20000–1. Other frameworks and practices can also be used to support ISO/IEC 20000–1.
Within this document, Clause 4 provides an overview of ISO/IEC 20000-1 and the SMS. Clause 5 applies Agile
principles to the SMS. Clause 6 applies DevOps principles to the SMS. In Clause 7, the benefits and caveats
surrounding the use of Agile, DevOps or a combination of the two in the SMS are discussed. Annex A provides
a correlation of ISO/IEC 20000-1 clauses to the Agile and DevOps frameworks.

© ISO/IEC 2024 – All rights reserved
vi
Technical Specification ISO/IEC TS 20000-15:2024(en)
Information technology — Service management —
Part 15:
Guidance on the application of Agile and DevOps principles in
a service management system
1 Scope
This document provides guidance on the relationship between ISO/IEC 20000–1:2018 and two commonly
used frameworks, Agile and DevOps. It can be used by any organization or person wishing to understand
how Agile and DevOps can be used with ISO/IEC 20000–1, including:
a) an organization that has demonstrated or intends to demonstrate conformity to the requirements
specified in ISO/IEC 20000–1 and is seeking guidance on the use of Agile or DevOps to establish or
improve the SMS and the services;
b) an organization that already uses Agile or DevOps and is seeking guidance on how Agile or DevOps can
be used to support efforts to demonstrate conformity to the requirements specified in ISO/IEC 20000–1;
c) an assessor or auditor who wishes to understand the use of Agile or DevOps as a support for achieving
the requirements specified in ISO/IEC 20000–1.
Both approaches can be used independently or together. Depending on the context, an organization can
deploy Agile frameworks only, DevOps frameworks only, use both Agile and DevOps frameworks in isolation,
or use an integrated workflow with combined Agile and DevOps approaches. In any of these situations, this
document can be used as guidance for the integration of Agile and DevOps practices in an SMS.
The guidance in this document can assist an organization in planning and preparing for a conformity
assessment against ISO/IEC 20000-1, noting that an organization can only claim conformity by fulfilling all
requirements specified in ISO/IEC 20000-1.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 20000-1, Information technology — Service management — Part 1: Service management system
requirements
1)
ISO/IEC 33202:— , Software and systems engineering — Core Agile practices
ISO/IEC/IEEE 32675, Information technology — DevOps — Building reliable and secure systems including
application build, package and deployment
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 20000-1, ISO/IEC 33202,
ISO/IEC/IEEE 32675 and the following apply.
1) Under preparation. Stage at the time of publication: ISO/IEC/FDIS 33202:2024.

© ISO/IEC 2024 – All rights reserved
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
Agile
collection of frameworks and techniques focusing on collaboration, iterative and incremental development
and continuous improvement
Note 1 to entry: In this context, the term "Agile" is usually capitalized.
3.2
bottom-up intelligence
use of information coming from users themselves, so they can develop better options to achieve valuable
objectives
3.3
continuous everything
increasing agility throughout the service lifecycle from testing, deployment and monitoring through to
integration and delivery
3.4
cradle-to-grave
activities from the beginning of the service lifecycle to its end or disposal
Note 1 to entry: This term is specifically used in this way within the context of DevOps.
3.5
cross-functional autonomous team
team that has the skills and disciplines required to achieve an established goal, such as developing, deploying
or operating a service
Note 1 to entry: These teams are fully empowered and self-sufficient for the designing, building, testing, deployment
and running of the service.
3.6
customer-centric
doing business and ensuring a positive customer experience at every stage of the customer journey (3.7)
Note 1 to entry: When a customer-centric organization makes a decision, its people thoroughly analyze its impact on
the customers.
3.7
customer journey
series or sum of customer experiences when engaging with an organization, its products or services
Note 1 to entry: “Series” is based on processes; “sum” is based on results.
[SOURCE: ISO 23592:2021, 3.8]
3.8
daily stand-up
short, daily, time-limited meeting used to discuss progress, plans and any blocking issues with each member
of an Agile (3.1) team
[SOURCE: ISO/IEC TR 24587:2021, 3.7, modified — The term "time-boxed" has been replaced by "time-
limited" at the beginning of the definition, and "Agile" has been capitalized. Note 1 to entry has been
removed.]
© ISO/IEC 2024 – All rights reserved
3.9
DevOps
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems products and
services, and continuous improvements in all aspects of the lifecycle
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1.1]
3.10
hypothesis
theory that something can become valuable, even though this will not be known for sure until it is verified in
a real environment
3.11
left-shift
shift-left
prioritizing the involvement of relevant stakeholders in applying quality activities, security, privacy,
performance, verification, and validation earlier in the lifecycle
Note 1 to entry: In this document, the expression “shift-left” is used, because it is more common in the industry.
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1.2, modified — Admitted term "shift-left" has been added. Note 1 to
entry has been added.]
3.12
minimum viable service
MVS
limited service release that includes the main hypotheses (3.10) that demonstrate whether the main product
idea makes sense to the customer
3.13
result-oriented plan
plan that focuses on outcome rather than on the process used to deliver a service
Note 1 to entry: Following a result-oriented plan gives a higher chance of being successful. It pushes the organization
to take ownership and be flexible in defining priorities. Most importantly, it enables the organization to measure
progress against a defined set of requirements.
3.14
retrospective
team meeting at the end of an iterative cycle or at the end of a project to reflect on what went well, what was
learned, and what should be done differently next time
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3488, modified — Preferred term has been changed from
"retrospective meeting" to "retrospective". "Software project" has been changed to "project" in the
definition.]
3.15
self-organizing team
team using its own knowledge to determine how best to do their job
3.16
servant leader
leader focusing on providing what the team need, removing impediments to their progress and supporting
their productivity
3.17
service-thinking
focusing on the end-goal or the outcome of the process or service

© ISO/IEC 2024 – All rights reserved
3.18
service backlog
list of items ordered by value of what is to be done or to be achieved
3.19
service owner
person responsible for maximizing the value that the service development team creates, including
managing the service backlog (3.18), identifying and prioritizing improvement opportunities and supporting
operations.
Note 1 to entry: Within the context of this document, this term is used specifically in reference to Agile environments.
Its use can be different within other service management environments.
3.20
technical debt
deferred cost of work not done at an earlier point in the service lifecycle
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4181, modified — "product life cycle" has been replaced with “service
lifecycle".]
3.21
user story
brief description of required functionality describing the stakeholder roles, goals, benefits and motivation
[SOURCE: ISO/IEC 33202:—, 3.28, modified — Note 1 to entry has been removed.]
3.22
vanity metrics
statistics that look spectacular on the surface but do not necessarily translate to any meaningful business results
4 Introduction to ISO/IEC 20000–1:2018
ISO/IEC 20000-1 specifies requirements for establishing, implementing, maintaining and continually
improving a service management system (SMS). An SMS supports the management of the service lifecycle,
including the planning, design, transition, delivery and improvement of services, which meet agreed
requirements and deliver value for customers, users and the organization delivering the services. The
organization in the scope of the SMS can be a whole or part of a larger organization and can also be known
as the "service provider".
ISO/IEC 20000-1 is intentionally independent of specific guidance. The organization can use a combination
of generally accepted frameworks (e.g. Agile, DevOps) and its own experience. Appropriate tools for service
management can be used to support the SMS.
All requirements specified in ISO/IEC 20000-1 are generic and are intended to be applicable to all
organizations, regardless of the organization’s type or size, or the nature of the services delivered. While
ISO/IEC 20000-1 can be used regardless of the organization’s type or size, or the nature of the services
delivered, the document has its roots in IT. It is intended for service management of services using technology
and digital information. The examples given in this document illustrate a variety of uses of ISO/IEC 20000-1.
Exclusion of any of the requirements in ISO/IEC 20000-1:2018, Clauses 4 to 10, is not acceptable when the
organization claims conformity to ISO/IEC 20000-1, irrespective of the nature of the organization.
The organization cannot demonstrate conformity to the requirements specified in ISO/IEC 20000-1 if other
parties are used to provide or operate all services, service components or processes within the scope of the SMS.
ISO/IEC 20000-10 includes the concepts for an SMS, the vocabulary used for the ISO/IEC 20000 series, a
description of each part of the series and related standards.
Guidance is available in other parts of the ISO/IEC 20000 series in the form of:
— ISO/IEC 20000-2, Guidance on the application of service management systems;

© ISO/IEC 2024 – All rights reserved
— ISO/IEC 20000-3, Guidance on scope definition and applicability of ISO/IEC 20000-1;
— ISO/IEC TS 20000-5, Implementation guidance for ISO/IEC 20000-1;
— ISO/IEC 20000-6, Requirements for bodies providing audit and certification of service management systems;
— ISO/IEC TS 20000-11, Guidance on the relationship between ISO/IEC 20000-1 and service management
frameworks: ITIL®;
— ISO/IEC TS 20000-14, Guidance on the application of Service Integration and Management to ISO/IEC 20000-1;
2)
— ISO/IEC TS 20000-16:— , Guidance on sustainability within a service management system based on
ISO/IEC 20000-1;
3)
— ISO/IEC TR 20000-17:— , Scenarios for the practical application of ISO/IEC 20000-1.
Figure 1 illustrates an SMS showing the clause content of ISO/IEC 20000-1.
NOTE Numbers in parentheses indicate ISO/IEC 20000-1 clause numbers.
Figure 1 — Service management system
2) Under preparation. Stage at the time of development: ISO/IEC WD TS 20000-16:2024.
3) Under preparation. Stage at the time of development: ISO/IEC CD TR 20000-17:2024.

© ISO/IEC 2024 – All rights reserved
5 Agile within an SMS based on ISO/IEC 20000–1
5.1 Background of Agile
To understand how Agile can help in service management, it is necessary to understand why Agile arose and
the problem it was aiming to solve.
In its initial conception, Agile emerged to respond to a common problem identified in software development.
In essence, it provided some guiding principles for answering the following question:
— How can one deliver valuable software to a customer when not even the customer is sure about what
they want?
In other words, Agile focuses on customer satisfaction above all else, but in an unpredictable environment,
also known as a high-uncertainty environment or a complex system. Value, the customer and uncertainty are
the key points from which all Agile philosophical principles stem. These principles are summarized in the
[13]
Agile Manifesto (see 5.2), and they are the source of inspiration for all Agile frameworks that exist today.
From the key points of the Agile Manifesto, a series of Agile Principles are derived (see 5.2).
Although Agile emerged to respond to a common problem that exists in software development, its benefits
have extended far beyond this discipline, and it has been tested in different sectors and contexts, some of
them far removed from the world of software, such as education or health.
In the following subclauses, several Agile concepts will be discussed and applied to the requirements of
ISO/IEC 20000-1.
5.2 Agile Principles
5.2.1 Overview
The Agile mindset has been expressed in terms of the Agile Manifesto and its related Principles (see
Reference [13]). This subclause contains a summary of the Agile Manifesto and the Agile Principles. The
Agile Manifesto and Agile Principles were written with software development in mind, but they can be
interpreted for the context of services.
NOTE In the following subclauses, the term "software" as used in Reference [13] has been replaced with the term
"service".
5.2.2 Agile Manifesto
The focus of Agile is to uncover better ways of delivering services by providing those services and helping
others also to provide services. This work has led to the valuation of:
— individuals and interactions over processes and tools;
— working services over comprehensive documentation;
— customer collaboration over contract negotiation;
— responding to change over following a plan.
Within this list, whilst the primary points (first element in each line) are considered the most important, the
secondary elements (second element in each line) are also considered valuable.
NOTE See Reference [13] for further details and original text.

© ISO/IEC 2024 – All rights reserved
5.2.3 List of Agile Principles
[13]
The twelve Agile Principles are listed as follows:
1) "Our highest priority is to satisfy the customer through early and continuous delivery of valuable
services."
2) "Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage."
3) "Deliver working service enhancements frequently, from a couple of weeks to a couple of months, with a
preference for the shorter timescale."
4) "Business people and the service provider must work together daily throughout the service lifecycle."
5) "Build services around motivated individuals. Give them the environment and support they need, and
trust them to get the job done."
6) "The most efficient and effective method of conveying information to and within service teams is face-
to-face conversation."
7) "Working services are the primary measure of progress."
8) "Agile processes promote sustainable development. The sponsors, developers and users should be able
to maintain a constant pace indefinitely."
9) "Continuous attention to technical excellence and good design enhances agility."
10) "Simplicity (the art of maximizing the amount of work not done) is essential."
11) "The best architectures, requirements and designs emerge from self-organizing teams."
12) "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behaviour accordingly."
Agile principles and practices have been used successfully in areas such as product development, service
development and other disciplines in a fast-moving, complex environment. In such a context, there is a
significant level of uncertainty in the scope of the project. To manage this uncertainty, Agile focuses on the
rapid release of a partial, but functional service, which is built upon in subsequent iterations until completion.
The customer is continually involved in the development to test and verify the desired functionality. After
each release, the work methodology and resulting functionality is evaluated and, if needed, improved. The
overall focus of an Agile approach is on the iterative and incremental creation of value for the organization
and for the customer through development of the service. This approach has led to the development of a
number of Agile frameworks [such as Scrum, Scaled Agile Framework (SAFe) and dynamic systems
development method (DSDM)], which all have commonalities that are described and can be applied to the
SMS in the following subclauses.
5.3 Agile and services
5.3.1 Value in a service environment
Within the services domain, there is an interest in maximizing the value that the service delivers to the
customer in environments of high uncertainty. The concepts of value, customer and uncertainty should
encourage reflection on how to approach the design, implementation and maintenance of the SMS and the
services.
The same issues that brought about the rise of Agile in software development can also be relevant to services,
for example:
— how to offer a valuable service to a customer without knowing if the service will help to best meet the
customer’s objectives;
© ISO/IEC 2024 – All rights reserved
— how to know if a service level agreement (SLA) or a key performance indicator (KPI) really adds value to
the end-customer;
— how to make service management evolve for the better, always keeping the customer’s objectives in mind.
ISO/IEC 20000-1:2018, 5.1, requires that top management ensure that what constitutes value for the
organization and its customers is determined. Customers often know what problems they seek to solve or
which new opportunities they want to take advantage of, but it is also common that an alternative solution
or opportunity for increased value is not identified. In such cases, Agile hypothesis and experimentation
can identify new opportunities to better serve the customers’ needs. Top management should therefore
encourage the organization’s service portfolio (see ISO/IEC 20000-1:2018, 8.2) to meet the customers’ needs;
an Agile approach can assist in identifying and exploiting previously undiscovered approaches.
The service that an organization delivers to a customer is itself a way of delivering value to the customer.
However, uncertainty is part of the reality of services. Ultimately, it is not possible to tell if a theoretical, lab-
designed, “perfect” service will actually fix problems or provide new opportunities for the customer until it
is implemented in a real-life environment.
Uncertainty relates to the management of issues and risks. ISO/IEC 20000-1:2018, 4.1 requires the
organization to consider internal and external issues affecting its ability to achieve the outcomes of the
SMS. ISO/IEC 20000-1:2018, 6.1 requires the organization to consider these issues and determine any risks
and opportunities that need to be addressed. An uncertain environment is a source of external and internal
issues that can constitute risks that require some form of actions to be addressed. Introducing the Agile
framework can be a way to address issues and risks resulting from an uncertain environment.
5.3.2 Value, customers and uncertainty in services
Services should be supportive of the customer’s business outcomes. Value creation is the primary objective
of setting up an SMS, as mentioned in the Introduction of ISO/IEC 20000-1:2018. However, it is possible for
an SMS to become too process-focused, losing the focus on the customer. ISO/IEC 20000-1:2018, Clause 4,
requires the organization to look at its context to support the design of the SMS which in turn helps to avoid
a purely process viewpoint and supports the reduction of risk associated with uncertainty. Essentially,
the organization should focus its efforts upon maximizing the value delivered to the client and in doing so
should find the right balance between the internal process focus and the focus on the customer’s needs and
expectations.
A service implemented in the real world with which the customer is satisfied is the best way to prove that
the service is valuable. With this in mind, ISO/IEC 20000-1:2018, 8.3.2, requires the organization to measure
satisfaction with the services based on a representative sample of customers. However, the activities
carried out within a service lifecycle are not always perceived as valuable by the customer. For example, it is
possible that the customer will not perceive value in configuration management which is largely invisible to
them but is essential to the smooth operation of a service. It can therefore be necessary to perform internal
procedures, write documentation or follow a methodology for the customer to ultimately perceive the value
of a service element. Ultimately, the customer perceives value if the service they receive solves a problem
or helps them to realize an opportunity. It is this value that the organization should determine and use as
guidance for the development of the SMS and the services.
With this in mind, all activities carried out as part of an SMS can be questioned at any time from the
perspective of whether or not they are truly necessary and have a real value contribution or, to the contrary,
are simply tasks to be adapted, or even eliminated, without this entailing a reduction in the value delivered
to the customer. The service management plan, as described in ISO/IEC 20000-1:2018, 6.3, is intended to
document what is necessary in an SMS to create value for the customers and the organization itself.
In Agile, value creation includes making sure that the organization offers the customer value using processes
that are designed for what the customers want to achieve with the services. This is distinct from offering
only services that provide basic functionality, but not much value to customers, with the rationale that they
are easy for the service provider to implement.

© ISO/IEC 2024 – All rights reserved
Using Agile methodologies can help to accelerate value creation for the customer and the service provider in
the following ways:
— through closer collaboration between the service provider and the customer, the customer’s needs and
expectations of the service are more clearly defined and implemented in the service;
— through iterative service development, service elements become available more quickly to the end users;
— through more efficient and effective testing methods, the quality and reliability of the service is improved;
— through the use of hypothesis testing (see 5.6), the elements which are valuable for the customer can be
more accurately determined.
5.4 Defining objectives
Setting objectives seeks to add "certainty" to an environment of "uncertainty". A clear objective should be
understood and shared by customer and the organization. This is essential for working effectively on the
development of the service.
Agile’s focus on value creation leads to a focus on the customer: the customer is after all the receiver of the
value created by the services. The organization should listen carefully to the customer and take feedback
about the provided services with the aim of improving them. In ISO/IEC 20000-1:2018, 5.1, top management
is considered responsible for ensuring that what constitutes value for the organization and its customers is
determined.
Leveraging Agile, the design of a service should start with the definition of a customer objective:
— What problem is to be solved for the customer?
— How is it possible to make the customer happier?
— What advantages can be given to them?
In this way, the customer can play an active role in determining the nature and shape of the services they are
willing to pay for.
The customer objective then acts as a source of inspiration. For this to hold true, service and service
management objectives (see ISO/IEC 20000-1:2018, 6.2) should focus on why that service and its supporting
SMS are necessary. There is sometimes a tendency to define the service objectives in terms of what should
be done, or the activities to be carried out. But it is preferable to ask "why is it important to perform these
activities?" in order to achieve the true objective.
EXAMPLE 1 A service objective is initially defined as “we want to offer an incident ticketing service to our users
based on a cloud system”. When asking, “why is it important that a cloud system is used?”, the answer can be “having a
cloud system is not essential. The goal is to facilitate the day-to-day work of users with respect to ticket management”.
In other words, the location of the ticket system is not important to the users; what they want is for incident ticket
management to improve so that their daily lives can be more efficient and comfortable, and so that communication
between the people involved can improve.
Presenting the service objective as initially shown in Example 1 forces the choice of a cloud system and
does not foster reflection on what the customer’s real problem is and how best to solve it. By questioning
the purpose behind the initial objective, as shown in the example, focus can be placed on understanding the
customer’s needs and expectations first (see ISO/IEC 20000-1:2018, 4.2), before moving on to proposing
solutions. This latter approach is more inspiring and provides greater flexibility for generating potential
solutions in the way the SMS and the services are developed.

© ISO/IEC 2024 – All rights reserved
Example 2 provides a continuation of Example 1.
EXAMPLE 2 During the implementation of the incident ticketing service, an end-user training gap is detected that
has much more importance for achieving the customer's objective than implementing a new cloud-based technology,
as specified initially. Setting an objective based on the issue to be solved allows for greater flexibility, as well as for
the prioritization of new opportunities that will potentially arise later on, instead of forcing the team to carry on with
what was initially planned (or even documented in an agreement). In this case, being flexible, adapting the proposal
and focusing on training users over other activities can bring the organization much closer to offering a service that is
truly valuable for the customer.
Agile achieves an understanding of the customer's requirements by closely working with the customer
to determine what value they want to create with the service and how these expectations translate into
service req
...