ISO/IEC 29110-5-4:2025

International
Standard
ISO/IEC 29110-5-4
First edition
Systems and software
2025-09
engineering — Life cycle profiles for
very small entities (VSEs) —
Part 5-4:
Agile software development
guidelines
Ingénierie des systèmes et du logiciel — Profils de cycle de vie
pour très petits organismes (TPO) —
Partie 5-4: Lignes directrices relatives au développement de
logiciels agiles
Reference number
© ISO/IEC 2025
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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3  Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .6
4  Naming, diagramming and definition conventions . 6
5 Overview . 7
5.1 General .7
5.2 Project management process of Basic profile and the agile events performed to manage
the project .7
5.3 Software implementation process of Basic profile and the agile events performed to
implement the project .8
5.4 Roles involved.9
6 Agile software development process .10
6.1 Agile project management process .10
6.1.1 Agile project management process purpose .10
6.1.2 Agile project management process outcomes .10
6.1.3 Overview of the agile project management process.10
6.2 Agile software implementation process .11
6.2.1 Agile software implementation process purpose .11
6.2.2 Agile software implementation process outcomes .11
6.2.3 Overview of the agile software implementation process . 12
6.3 Event 1 - project vision meeting (contributes to outcome PM.O1) . 13
6.3.1 Justification . 13
6.3.2 Overview of event 1- project vision meeting .14
6.3.3 Tasks of event 1 - project vision meeting .14
6.4 Event 2 - estimation meeting (contributes to outcomes PM.O1, PM.O5) . 15
6.4.1 Justification . 15
6.4.2 Overview of the event 2 - estimation meeting . 15
6.4.3 Tasks of event 2 - estimation meeting .16
6.5 Event 3 - sprint planning (contributes to outcomes PM.O1, PM.O2, PM.O4, PM.O7, SI.O1,
SI.O3, SI.O5) .17
6.5.1 Justification .17
6.5.2 Overview of event 3 – sprint planning .18
6.5.3 Tasks of event 3 – sprint planning .18
6.6 Event 4 – sprint (contributes to outcomes PM.O2 PM.O3, SI.O3, SI.O4, SI.O5, SI.O7) .21
6.6.1 Justification .21
6.6.2 Overview of event 4 – sprint .21
6.6.3 Tasks of event 4 - sprint . 22
6.7 Event 5 - daily scrum (contributes to outcomes PM.O2, PM.O3, PM.O4, PM.O5, PM.O7) . 25
6.7.1 Justification . 25
6.7.2 Overview of event 5 - daily scrum . 25
6.7.3 Tasks of event 5 - daily scrum . 25
6.8 Event 6 - sprint review (contributes to outcomes PM.O2, PM.O3, PM.O4, SI.O5, SI.O7) .27
6.8.1 Justification .27
6.8.2 Overview of event 6 – sprint review .27
6.8.3 Task of event 6 – sprint review .27
6.9 Event 7 - sprint retrospective (contributes to outcomes PM.O2, PM.O3, PM.O4, PM.O7) . 30
6.9.1 Justification . 30
6.9.2 Overview of event 7 – sprint retrospective . 30
6.9.3 Task of event 7 – sprint retrospective . 30

© ISO/IEC 2025 – All rights reserved
iii
7 Role descriptions .32
8 Work products description .35
Annex A (informative) Example of work products templates .59
Annex B (informative) Overview of popular agile methods .65
Annex C (informative) Development of the guidelines for the reinforcement of an agile
environment . 67
Annex D (informative) Development of the guidelines for the reinforcement of an agile
environment .70
Bibliography .72

© ISO/IEC 2025 – 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 7, Software and systems engineering.
A list of all parts in the ISO/IEC 29110 series can be found on the ISO website.
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.

© ISO/IEC 2025 – All rights reserved
v
Introduction
0.1  Introduction to the ISO/IEC 29110 series
For the purpose of the ISO/IEC 29110 series, a very small entity (VSE) is an enterprise, organization (e.g.
government agency, non-profit organization), department or project having up to 25 people. Since many VSEs
develop and/or maintain system and software components used in systems, either as independent products
or incorporated in larger systems, a recognition of VSEs as suppliers of high-quality products is required.
VSEs around the world are creating valuable products and services. According to the World Bank, small
and medium-sized enterprises (SMEs) account for about 90 % of enterprises worldwide. According to the
Organisation for Economic Co-operation and Development (OECD), SMEs represent 99 % of all businesses
and generate about 60 % of employment. Almost one person out of three is employed in a micro firm with
less than 10 employees. The European Union reports that micro firms, with fewer than 10 persons, account
for 93,5 % of all enterprises and small firms, with 10 to 49 employees, account for 5,5 % of all enterprises.
The challenge facing governments is to provide a business environment that supports the competitiveness
of this large heterogeneous business population and that promotes a vibrant entrepreneurial culture.
From studies and surveys conducted, the majority of International Standards do not address the needs of
VSEs. Implementation of and conformity with these standards is difficult, if not impossible.
Consequently, VSEs have no, or very limited, ways to be recognized as entities that produce quality systems/
system elements including software in their domain. Therefore, VSEs are excluded from some economic
activities.
It has been found that VSEs find it difficult to relate International Standards to their business needs and to
justify the effort required to apply standards to their business practices. Most VSEs find it helpful to have
detailed, specified, procedures when beginning agile projects, rather than attempting to interpret and tailor
the more flexible, high-level process requirements of ISO/IEC/IEEE. To address some of these difficulties,
a set of guidelines have been developed based on a set of VSEs characteristics. The guidelines are based
on subsets of appropriate standards processes, activities, tasks, and outcomes, referred to as profiles.
The purpose of a profile is to define a subset of International Standards relevant to the VSEs' context;
for example, processes, activities, tasks, and outcomes of ISO/IEC/IEEE 12207 for software systems; and
processes, activities, tasks, and outcomes of ISO/IEC/IEEE 15288 for systems; and information products
(documentation) of ISO/IEC/IEEE 15289 for software and systems.
VSEs can achieve recognition through implementing a profile and by being audited against ISO/IEC 29110
specifications.
The ISO/IEC 29110 series can be applied at any phase of system or software development within a life
cycle. The ISO/IEC 29110 series is intended to be used by VSEs that do not have experience or expertise in
adapting/tailoring ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 standards to the needs of a specific project.
VSEs that have expertise in adapting/tailoring ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288 are encouraged
to use those standards instead of the ISO/IEC 29110 series.
The ISO/IEC 29110 series is intended to be used with any life cycle such as: waterfall, iterative, incremental,
evolutionary or agile.
Systems, in the context of the ISO/IEC 29110 series, are typically composed of hardware and software
components.
The ISO/IEC 29110 series, targeted by audiences, has been developed to improve system or software and/
or service quality, and process performance. Figure 1 describes the ISO/IEC 29110 series and positions the
parts within the framework of reference.

© ISO/IEC 2025 – All rights reserved
vi
Figure 1 — ISO/IEC 29110 series
ISO/IEC 29110-1-1 introduces processes, life cycle and standardization concepts, the taxonomy (catalog) of
ISO/IEC 29110 profiles and the ISO/IEC 29110 series. ISO/IEC 29110-1-1 also introduces the characteristics
and needs of a VSE, and clarifies the rationale for specific profiles, documents, standards and guidelines.
ISO/IEC 29110-1-2 defines the terms common to the ISO/IEC 29110 series. ISO/IEC 29110-1-1 and
ISO/IEC 29110-1-2 are targeted at VSEs and their customers, assessors, standards producers, tool vendors
and methodology vendors.
ISO/IEC 29110-2 introduces the concepts for systems and software engineering profiles for VSEs. It
establishes the logic behind the definition and application of profiles. For standardized profiles, it specifies
the elements common to all profiles (structure, requirements, conformity, and assessment). For domain-
specific profiles (profiles that are not standardized and developed outside of the ISO process), it provides
general guidance adapted from the definition of standardized profiles. ISO/IEC 29110-2 is targeted at profile
producers, tool vendors and methodology vendors.
ISO/IEC 29110-3 defines certification schemes, assessment guidelines and compliance requirements for
process capability assessment, conformity assessments, and self-assessments for process improvements.
ISO/IEC 29110-3 also contains information that can be useful to developers of certification and assessment
methods and developers of certification and assessment tools. ISO/IEC 29110-3 is addressed to people who
have direct involvement with the assessment process, e.g. the auditor, certification and accreditation bodies
and the sponsor of the audit, who need guidance on ensuring that the requirements for performing an audit
have been met. ISO/IEC 29110-3 is targeted at VSEs and their customers, assessors, accreditation bodies.

© ISO/IEC 2025 – All rights reserved
vii
ISO/IEC 29110-4 provides the specifications for all generic profiles of the Generic profile group that are
based on subsets of appropriate standards elements. ISO/IEC 29110-4 is targeted at VSEs, customers,
standards producers, tool vendors and methodology vendors.
ISO/IEC 29110-5 provides management, engineering and service delivery guidelines for profiles of the
Generic profile group. ISO/IEC 29110-5 is targeted at VSEs and their customers.
ISO/IEC 29110-6 provides the specifications for specific profiles that are based on subsets of appropriate
standards elements. ISO/IEC 29110-6 is targeted at VSEs, customers, standards producers, tool vendors and
methodology vendors.
ISO/IEC 29110-7 provides guidelines for each profile of the specific profile group. ISO/IEC 29110-7 is targeted
at VSEs and their customers.
If a new profile is needed, ISO/IEC 29110-4 or ISO/IEC 29110-6 and or ISO/IEC 29110-7, ISO/IEC 29110-5 can
be developed with minimal impact to existing documents.
0.2  Introduction to this document
This document aims to help VSEs that want to reinforce their agile environment to develop software products
using an agile approach with practices of the ISO/IEC 29110 series. Therefore, it can be implemented by
organizations or projects that are implementing and using an agile environment and want to reinforce it
using the processes and products recommended by this document.
This document provides examples of work products templates (see Annex A).
This document is based mainly on the scrum and XP agile methods (see Annex B).
This document also aims to help VSEs that want to initiate a certification of the two processes of the software
Basic profile of the ISO/IEC 29110, as specified in ISO/IEC 29110-4-1, while performing their agile practices
(see Annex C).
This document has been developed, using the management and engineering guidelines of the
ISO/IEC 29110-5-1-2 software Basic profile, by modifying and adding elements (e.g. task, work product,
role) for VSEs involved in the development of software using an agile approach (see Annex C). However, this
document does not contain any requirements; and organizations cannot claim conformity to this document.
Using this document, VSEs can obtain the following benefits:
— project planning: by providing a set of events to enable the team to track the work and know what an
impediment can be and assign tasks to each member of the team;
— effort estimation: by providing estimation techniques for the sprint planning event;
— progress tracking: by providing tools (e.g. burndown chart, product backlog, daily scrum) to update and
track the work, the budget and the schedule until the project's closure;
— management of changes and artefacts: by providing a set of tasks to control the changes to the software
and management work products;
— clarity of each role: by providing a set of tasks for each role;
— agile risk management: by providing work products to identify and manage risks;
— reduced rework: by providing a set of tasks that minimize errors and handle the detection and correction
of defects effectively.
© ISO/IEC 2025 – All rights reserved
viii
International Standard ISO/IEC 29110-5-4:2025(en)
Systems and software engineering — Life cycle profiles for
very small entities (VSEs) —
Part 5-4:
Agile software development guidelines
1 Scope
This document provides guidelines for very small entities (VSEs) that want to reinforce their agile
environment to develop software using an agile approach with practices of the ISO/IEC 29110 series.
This document is applicable to VSEs that do not develop business- or safety-critical products.
2 Normative references
The following documents are referred to in the text in such a way that some or all 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 29110-1-2, Systems and software engineering — Lifecycle profiles for Very Small Entities (VSEs) — Part
1-2: Vocabulary
3  Terms, definitions and abbreviated terms
3.1  Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 29110-1-2 and the following apply.
ISO and IEC maintain terminological 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.1
acceptance criteria
working agreement (3.1.6) on the required quality attribute that work meets before it completes a specified
story or feature, item or artefact
3.1.2
agile
approach to development, delivery and maintenance of products and services by enabling rapid response to
feedback
Note 1 to entry: The required specification for the software under development is elaborated with specific
requirements only when the work is started. This lean principle is meant to avoid waste of work and to provide an
agile team (3.1.5) with means of prioritizing their work.
[SOURCE: ISO/IEC 33202:2024, 3.2, modified — "need specification" has been replaced by "required
specification".]
© ISO/IEC 2025 – All rights reserved
3.1.3
agile development
development approach based on iterative development, frequent inspection and adaptation, and incremental
deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and
through continuous stakeholder feedback
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — Note 1 to entry has been removed.]
3.1.4
agile environment
organizational culture, infrastructure, and methodologies that support agile development (3.1.3)
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.2]
3.1.5
agile team
organization or team using agile development (3.1.3) methods and approaches
Note 1 to entry: Typically, with roles such as team lead, project manager, user or user representative, software and
information developers, and testers
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.3]
3.1.6
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.5]
3.1.7
backlog
collection of agile (3.1.2)features (3.1.15) or stories of both functional and non-functional requirements that
are typically sorted in an order based on value priority
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.4]
3.1.8
baseline
formally approved version of a configuration item, regardless of media, formally designated and fixed at a
specific time during the configuration item’s life cycle
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.11]
3.1.9
build
operational version of a system or component that incorporates a specified subset of the capabilities that the
final product will provide
[SOURCE: IEEE 828-2012, 2.1, IEEE dictionary]
3.1.10
burndown chart
graph that represents the work remaining to do on a project
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.6]
3.1.11
burnup chart
graphical representation of the work completed toward the release of a product
[SOURCE: Agile Practice Guide, Project Management Institute, 2017]

© ISO/IEC 2025 – All rights reserved
3.1.12
continuous integration
technique that continually merges artefacts, including source code updates from all developers on a team,
into a shared mainline to build and test the developed system
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1]
3.1.13
definition of done
DoD
statement on the required quality attributes that work meets before the work completes a specified life
cycle activity or task and is ready for use
[SOURCE: ISO/IEC 33202:2024, 3.13]
3.1.14
event
ceremony
key meeting in which a set of tasks are performed to help the scrum leader (3.1.28), product owner (3.1.20),
and developer to organize, evaluate, and adjust the work to be done to develop a product
EXAMPLE Sprint (3.1.31) planning, daily scrum (3.1.29), sprint review and sprint retrospective.
3.1.15
feature
functional or non-functional distinguishing characteristic of a system
Note 1 to entry: A feature, item or artefact is usually an enhancement to an existing system.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.7, modified — The original note 1 to entry has been replaced by a
new one.]
3.1.16
increment
tested, deliverable version of a software product (3.1.30) that provides new or modified capabilities
[SOURCE: ISO/IEC 33202:2024, 3.17]
3.1.17
pair programming
practice from eXtreme Programming (XP) that typically involves one developer writing source code
or configuring a system while a second developer observes the work to look for errors and to determine
whether the work completed is accurate and meets its requirements
Note 1 to entry: Pairs alternate roles periodically so a different developer writes code while the other developer
observes.
3.1.18
planning poker
team-based estimation approach whereby relative estimates of the effort required to develop and test each
user story (3.1.37) are set via consensus
Note 1 to entry: The approach uses poker cards that are typically based on a Fibonacci sequence (i.e. 1, 2, 3, 5, 8, 13).
3.1.19
product backlog
It is an emergent, ordered list of what is needed to improve the product. It is the single source of work
undertaken by the agile team (3.1.5)

© ISO/IEC 2025 – All rights reserved
3.1.20
product owner
designated stakeholder accountable for defining and accepting outcomes of the work and managing backlog
(3.1.7), while aligning with the stakeholder needs
Note 1 to entry: A product owner is also the 'voice of the user' or the user representative on the team.
[SOURCE: ISO/IEC 33202:2024, 3.2, modified — Note 1 to entry has been added.]
3.1.21
process purpose
high-level objective of performing the process and the likely outcomes of effective implementation of the process
[SOURCE: ISO/IEC/IEEE 24774:2021, 3.12]
3.1.22
process outcome
observable result of the successful achievement of the process
[SOURCE: ISO/IEC/IEEE 24774:2021, 3.11]
3.1.23
profile
subset of appropriate standards’ processes and their outcomes, activities and tasks combined to accomplish
a particular function
Note 1 to entry: The base standards used to develop profiles for VSEs are ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288
and ISO/IEC/IEEE 15289.
3.1.24
repository
organized and persistent data storage that allows data retrieval
[SOURCE: ISO/IEC/IEEE 26511:2018, 3.1.24]
3.1.25
safety-critical product
software whose failure or malfunction can result in one (or more) of the following outcomes:
— death or serious injury to people
— loss or severe damage to equipment or property
— environmental harm
[SOURCE: ISO/IEC 23643:2020, 3.15, modified — EXAMPLE has been removed.]
3.1.26
self-organizing team
group composed of motivated individuals working together toward meeting a goal
Note 1 to entry: They have the ability and authority for decision-making. They manage their work and readily adapt
for changing demands.
Note 2 to entry: Principles of self-organizing teams are competency, collaboration, motivation, trust, respect and
continuity.
3.1.27
scrum
iterative project management framework used in agile development (3.1.3), in which a team agrees on
development items from product backlog (3.1.19) and produces them within a short duration of a few weeks
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3637]

© ISO/IEC 2025 – All rights reserved
3.1.28
scrum leader
person who facilitates the scrum (3.1.27) process within a team or project
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3638, modified — The term has been changed from "scrum master"
to "scrum leader".]
3.1.29
daily scrum
in agile development (3.1.3) methods, brief daily meeting where team members share accomplishments from
the prior daily meeting, plans for the current day and identification of impediments
Note 1 to entry: The product backlog (3.1.19) is sorted in prioritized order.
3.1.30
software product
set of computer programs, procedures, and possibly associated documentation and data
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.54, modified — Note 1 to entry has been removed.]
3.1.31
sprint
short time frame, in which a set of software features (3.1.15) is developed, leading to a working product that
can be demonstrated to stakeholders
Note 1 to entry: In some organizations, a sprint is known as an iteration.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3914]
3.1.32
sprint backlog
iteration backlog
sprint catalogue
set of backlog (3.1.7) items [e.g. user stories (3.1.37)] that are selected for inclusion in a given sprint (3.1.31)
3.1.33
story points
units of measure for expressing an estimate of the overall effort required to fully implement a product
backlog (3.1.19) item or any other piece of work
3.1.34
time-boxed
having prescribed duration limit for a project task
[SOURCE: Adapted from Software Extension to the PMBOK Guide Fifth Edition]
3.1.35
task board
kanban board
scrum board
visual representation of an agile team's (3.1.5) progress within an iteration
3.1.36
unit test
testing of individual routines and modules by the developer or an independent tester
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4429, definition 1]
3.1.37
user story
brief description of desired functionality
Note 1 to entry: User story can describe the stakeholder roles, goals, benefits, and motivation.

© ISO/IEC 2025 – All rights reserved
Note 2 to entry: Work in backlog (3.1.7) can be referred in other ways like epics, features, items or artefacts.
[SOURCE: ISO/IEC 33202:2024, 3.1.54, modified — In Note 2 to entry, "items or artefacts" has been added.]
3.1.38
velocity
rate of current work unit completion, measured as work units completed per fixed time period, such as
story points (3.1.33), delivered features (3.1.15), functions, function points, user stories (3.1.37), use cases, or
requirements completed in a given time period
Note 1 to entry: Used as a measure of burndown rate or burnup rate.
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1]
3.2  Abbreviated terms
DT developers
CUS customer
PM project management
PJM project manager
PO product owner
SI software implementation
SL scrum leader
TE task event
TL technical leader
WP work product
4  Naming, diagramming and definition conventions
This clause provides a description of the process structure, and the notation used to describe the processes.
Process name – process identifier, followed by its abbreviation in parentheses “( )”.
Process purpose – high level objective of performing the process and the likely outcomes of effective
implementation of the process.
Process outcomes – observable result of the successful achievement of the process purpose. Outcomes are
identified by the abbreviation of the process name, followed by the letter “O” and a consecutive number, for
example PM.O1, SI.O2.
Events – key meetings throughout the software development to organize, evaluate, and adjust the work to be
done to develop a product in an agile environment. For the purpose of this guide, an event is composed of a set
of tasks to be performed. An event is the first level of process workflow decomposition, and the second one is
a task. Events are identified by a process name abbreviation followed by a consecutive number and the event
name. Each event description is identified by the event name and the list of related outcomes surrounded
by parentheses “()”. For example, PM.O1 Project planning (PM.O1, PM.O5, PM.O6, PM.O7) means the event
PM.O1 Project planning contributes to the achievement of the listed outcomes: PM.O1, PM.O5, PM.O6 and
PM.O7. The event description begins with the task summary and is followed by the task descriptions table.
The selection of the techniques or methods is left to the VSE or project team.
Input work products – work products required to perform the process and its corresponding source, which
can be another process or an external entity to the project, such as the customer. They are identified by

© ISO/IEC 2025 – All rights reserved
the abbreviation of the process name and shown as two column tables of work product names and sources.
Parentheses after the work product name show the state of the work product.
Output work products – work products generated by the process and its corresponding destination, which
can be another process or an external entity to the project, such as customer or organizational management.
They are identified by the abbreviation of the process name and shown as two column tables of work product
names and destinations. Parentheses after the work product name show the state of the work product.
Internal work products – work products generated and consumed by the process itself. An internal work
product is not reviewed or approved by the customer. They are identified by the abbreviation of the process
name and shown as one column table of the work product names. Parentheses after the work product name
show the state of the work product.
Roles involved – names and abbreviations for the sets of tasks and responsibilities which project team
members are assigned. Several roles may be played by a single person, and one role may be assumed by
several persons. Roles are assigned to project participants based on the characteristics of the project. The
role list is identified by the abbreviation of the process name and shown as a two-column table. See Table 8
for the alphabetical list of the roles, its abbreviations and required competencies description.
Diagram – graphical representation of the processes. The large round-edged rectangles indicate an event,
and the smaller square-edged rectangles indicate the work products. The directional or bidirectional thick
arrows indicate the major flow of information between events. The thin directional or bidirectional arrows
indicate the input or output work products. The notation used in the diagrams does not imply the use of any
specific process life cycle.
Task – description of the task to be performed. The agile practices to be performed from an agile method
such as scrum or XP. Therefore, an agile task is identified by indicating that is a task event TE; PM or SI that
specifies if it is a project management event or a software implementation event, and the event number with
a consecutive number, for example TE.PM.1.2, TE.PM.2.1, TE.SI.1.1.
Input work products - work products needed to execute a task.
Output work products - work products created or modified by the execution of a task.
Incorporation to organizational repository – list of work products to be saved in organizational repository.
NOTE 1 Tables used in the process description are for presentation purpose only.
NOTE 2 The term ‘Basic’ is using a capital ‘B’ to indicate an ISO/IEC 29110 profile (e.g. the Basic profile) while the
term ‘basic’ is used when referring to the most important part of something (e.g. basic principles).
5 Overview
5.1 General
This clause provides guidelines for VSEs that want to reinforce their agile environment to develop software
using an agile approach with practices of the ISO/IEC 29110 series. See Annex C for more detail on how this
document was developed.
5.2  Project management process of Basic profile and the agile events performed to manage
the project
Figure 2 presents an overview of the project management process of the software Basic profile compared
with the events of the scrum method performed to manage the project. The events not related to project
management are greyed. Each event is described in detail in Clause 6.

© ISO/IEC 2025 – All rights reserved
Figure 2 — Overview of the project management process of the Basic profile and the agile events
5.3  Software implementation process of Basic profile and the agile events performed to
implement the project
Figure 3 presents an overview of the software implementation process of the software Basic profile
compared with the events of the scrum method performed to implement the project. The events not related
to software implementation are greyed. Each event is described in detail in Clause 6.

© ISO/IEC 2025 – All rights reserved
Figure 3 — Overview of the software implementation process of the Basic profile and the agile events
5.4 Roles involved
The list of roles involved for the project management events are:
— Customer
— Product owner
— Scrum leader
— Developers
The list of roles involved for the software implementation events are:
— Customer
— Developers
— Product owner
— Scrum leader
© ISO/IEC 2025 – All rights reserved
6 Agile software development process
6.1 Agile project management process
6.1.1 Agile project management process purpose
The purpose of the agile project management process is to achieve the project’s time, quality and cost
objectives by establishing and executing the tasks of the software implementation project systematically.
It also carries out administrative tasks relating to the storage, handling, protection and delivery of work
products and configuration items.
This document is intended to be used by the VSE to establish processes to implement agile approach based
on the VSE or project needs
6.1.2 Agile project management process outcomes
PM.O1. The project plan for the execution of the project is developed according to the agreement and
reviewed and accepted by the customer. The tasks and resources necessary to complete the work are sized
and estimated.
PM.O2. The progress of the project is monitored against the project plan and recorded in the progress
status record. The customer approves changes to the project plan. Corrections to remediate problems and
deviations from the plan are taken when project targets are not achieved. Closure of the project is performed
to get the customer acceptance documented in the acceptance record.
PM.O3. The change requests are addressed through their reception and analysis. Changes to software
requirements are evaluated for cost, schedule and technical impact. Change requests that impact the project
plan, the requirements or the agreement are approved by the customer.
PM.O4. Review meetings with the work team and the customer are held. Agreements are registered and
tracked.
PM.O5. Risks are identified as they develop and during the conduct of the project.
PM.O6. A software version control strategy is developed. Items of software product are identified, defined
and baselined. Modifications and releases of the items are controlled and made available to the customer
and work team. The storage, handling and delivery of the items are controlled.
PM.O7. Software quality assurance is performed to provide assurance that work products and processes
comply with the project plan and requirements specification.
NOTE Software quality assurance is implemented through the performance of the verification, validation and
review tasks perform
...