ISO/IEC/IEEE 26515:2018

INTERNATIONAL ISO/IEC/
STANDARD IEEE
Second edition
2018-12
Systems and software engineering —
Developing information for users in
an agile environment
Ingénierie du logiciel et des systèmes — Développement
d'informations pour les utilisateurs dans un environnement agile
Reference number
©
ISO/IEC 2018
©
IEEE 2018
© ISO/IEC 2018
© IEEE 2018
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 or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2018 – All rights reserved
ii © IEEE 2018 – All rights reserved

Contents Page
Foreword .iv
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 3
5 Information development process . 3
6 Management of information development . 4
6.1 Change management for agile development . 4
6.2 Composition of agile development teams . . 5
6.2.1 General. 5
6.2.2 Communication in agile development teams . 5
6.2.3 Globally distributed teams . 5
6.3 Management of information development across teams using agile development . 6
6.4 Management of information development tasks across iterations . 7
6.4.1 Planning the project as a whole . 7
6.4.2 Sizing and resourcing each iteration . 8
6.4.3 Handling last-minute content changes . 9
6.5 Monitoring and analysing progress . 9
6.5.1 General. 9
6.5.2 Stand-up meetings.10
6.5.3 Monitoring progress .10
6.5.4 Rework and changing requirements .11
6.6 Stakeholder involvement .11
6.6.1 General.11
6.6.2 Assessing customer satisfaction .11
7 Preparing information for users.12
7.1 Relationship of agile development to information development .12
7.2 Product design and developing information for users .12
7.3 Design and development of information for users .13
7.3.1 User requirements.13
7.3.2 Design techniques .14
7.3.3 Scheduling of design work .16
7.3.4 Planning of information for users .17
7.4 Reviewing and testing information for users .17
7.4.1 General.17
7.4.2 Reviewing information for users .17
7.4.3 System test of information for users.18
7.4.4 Usability testing of information for users .18
7.5 Translation and localization of information for users .18
7.6 Production of information for users .19
7.7 Delivering information for users with a continuous delivery process (DevOps) .19
Annex A (informative) Agile development practices .20
Bibliography .22
IEEE notices and abstract .23
© ISO/IEC 2018 – All rights reserved
© IEEE 2018 – All rights reserved iii

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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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 ISO documents should be noted. This document was drafted in accordance with the
rules given in the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).
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.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 26515:2011) which has been
technically revised.
The main changes compared to the previous edition are as follows:
— alignment with the widespread use of agile methods to include systems as well as software;
— replacement of the paper-based term “documentation” with the general term “information for
users” where appropriate;
— inclusion of agile information development across multiple teams and projects, especially projects
in continuous maintenance situations such as DevOps;
— editorial changes;
— new definitions.
© ISO/IEC 2018 – All rights reserved
iv © IEEE 2018 – All rights reserved

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 2018 – All rights reserved
© IEEE 2018 – All rights reserved v

Introduction
Software with an application user interface should generally be intuitive for most users or follow
common user interface conventions to limit the need for exhaustive or detailed information for users.
However, users should be provided with accurate information about how to use the software’s functions
if questions arise. This information should explain the major features or use cases deliberately created
for all types of users. The information should be easily accessible and clearly written to enable quick
learning and user proficiency, while reducing help desk support. Hence, well-designed information
not only assists the users and helps to reduce the cost of training and support, but also enhances the
reputation of the product, its producer, and its suppliers.
Projects that use agile development methods focus on providing rapid and frequent deliveries of
high-value software. These methods often involve detailed planning only for the short term and the
implementation of processes in parallel, rather than planning for an entire project in distinct phases.
Although agile development methods often advocate less life cycle documentation, the users of a
software product still expect and require quality information to be provided with these software
products. Although the end results of the process for developing information for users are the same, the
methods may be very different in an agile environment.
Agile development methods follow usually short, iterative development cycles based on customer
requirements and feedback. In order to fulfil contractual requirements and provide valuable
information for users, deliverables for each iteration include information related to the feature set
developed during that iteration. The quantity and quality of the information deliverables depend in part
on the completeness and maturity of the software features and design after each iteration, specified
through user stories, tasks, and personas.
Information developers and other personnel involved in developing information for users should
understand the agile development processes and methods used by their organization. This will enable
them to tie in seamlessly and provide relevant and useful information for users.
Because of the nature of agile development methods, the traditional means of developing information
(both print and onscreen) for end users are not entirely applicable.
This document was developed to assist users of
— ISO/IEC/IEEE 15288, Systems and software engineering — System life cycle processes,
— ISO/IEC/IEEE 12207, Systems and software engineering — Software life cycle processes,
— ISO/IEC 26514:2008, Systems and software engineering — Requirements for designers and developers
of user documentation (also available as IEEE Std 26514-2010, IEEE Standard for Adoption of ISO/
IEC 26514:2008, Systems and Software Engineering — Requirements for Designers and Developers of
User documentation), and
— Other documents in the ISO/IEC/IEEE 265NN family of International Standards.
This document provides requirements and guidance to information developers and related roles on
how to adapt the processes described in the ISO/IEC/IEEE 265NN family of International Standards to
develop quality information for users.
This document is independent of the agile development methods and tools that are used to produce the
software. This document gives an overview of agile methodologies although it neither encourages nor
discourages the use of any particular agile methodology. Therefore, this document uses generic agile
terminology as much as possible.
© ISO/IEC 2018 – All rights reserved
vi © IEEE 2018 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 26515:2018(E)
Systems and software engineering — Developing
information for users in an agile environment
1 Scope
This document supports the interest of information developers and associated roles responsible for
producing information for users of software and systems developed within an agile environment. This
document takes a process standard approach to specify the way in which information for users can be
developed in agile development projects.
This document provides requirements of information management and information development
processes appropriate for software projects that are using agile development methods.
Clause 5 covers the overall requirements for information in agile software development.
Clause 6 covers requirements for the information development lead or project manager to plan an
agile information development project and manage the information development activities in an agile
environment.
Clause 7 covers requirements for designing, developing, and providing information for users in an agile
environment.
Annex A describes agile development practices and methods.
This document is intended neither to encourage nor to discourage the use of any particular agile
development tools or methods.
This document provides guidance on processes appropriate for information developers of information
for users in software and systems projects that are using agile development methodologies. It is not
limited to the development phase of the life cycle of information for users, but includes activities
throughout the whole life cycle.
This document is intended for use in all organizations that are using agile development or are
considering implementing their projects using these techniques. It is assumed that users of this
document have experience or general knowledge of information for users (traditionally called “user
documentation”) and agile processes.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at https: //www .iso .org/
— IEC Electropedia: available at https: //www .electropedia .org/
— IEEE Standards Dictionary Online: available at https: //ieeexplore .ieee .org/xpls/dictionary .jsp
© ISO/IEC 2018 – All rights reserved
© IEEE 2018 – All rights reserved 1

3.1
agile development
development approach based on iterative development (3.11), frequent inspection and adaptation, and
incremental deliveries in which requirements and solutions evolve through collaboration in cross-
functional teams and through continuous stakeholder (3.13) feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology. Various agile methods can be
found in Annex A.
3.2
agile environment
organizational culture, infrastructure, and methodologies that support agile development (3.1)
3.3
agile team
organization or team using agile development (3.1) methods and approaches
Note 1 to entry: Typically with roles such as team lead, project manager, user or user representative, software
and information developers (3.8), and testers.
3.4
backlog
collection of agile features (3.7) or stories of both functional and nonfunctional requirements that are
typically sorted in an order based on value priority
3.5
done
regarded by the agile team (3.3) as complete and ready to use
3.6
epic
major collection of related feature sets broken down into individual features (3.7) or user stories (3.16)
and implemented in parts over a longer period of time
3.7
feature
functional or nonfunctional distinguishing characteristic of a system
Note 1 to entry: Features are considered to add value for the user.
3.8
information developer
person who prepares content for information for users
3.9
information development lead
person who leads the activities of preparing information for users
3.10
iteration
short time frame in which a set of software features (3.7) is developed, leading to a working product
that can be demonstrated to stakeholders (3.13)
Note 1 to entry: Different agile methodologies use different terms for an iteration.
Note 2 to entry: Some agile methodologies are not based on iterations.
3.11
iterative development
repeated use of concurrent planning, developing, and testing activities
© ISO/IEC 2018 – All rights reserved
2 © IEEE 2018 – All rights reserved

3.12
persona
model of a user with defined characteristics, based on research
3.13
stakeholder
individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.44, modified — The example and note to entry have been
deleted.]
3.14
stand-up meeting
brief daily project status or planning meeting used in agile development (3.1) methodologies
Note 1 to entry: Different agile methodologies use different terms for stand-up meetings.
3.15
use case
description of behavioural requirements of a system and its interaction with a user
Note 1 to entry: A use case describes the users' goal and the requirements including the sequence of interactions
between users and the system.
3.16
user story
simple narrative illustrating a user requirement from the perspective of a persona (3.12)
4 Conformance
This document may be used as a conformance or a guidance document for projects and organizations
claiming conformance to ISO/IEC/IEEE 15288 and/or ISO/IEC/IEEE 12207.
Throughout this document, “shall” is used to express a provision that is binding, “should” to express
a recommendation among other possibilities, and “may” to indicate a course of action permissible
within the limits of this document. Use of the nomenclature of this document for the features of an
agile methodology or the parts of information for users (that is, stand-up meetings, iterations, chapters,
topics, pages, screens, windows, etc.) is not required to claim conformance.
Conformance to this document may only be claimed by an organization if all of the requirements in this
document can be met by the organization. When conformance is claimed for a multisupplier program, it
may be the case that no individual supplier may claim conformance because no single contract calls for
all the required activities. Nevertheless, the program, as a whole, may claim conformance if each of the
required activities is performed by an identified party.
This document may be included or referenced in contracts or similar agreements when the parties
(called the acquirer and the supplier) agree that the supplier shall deliver information for users
in accordance with this document. It may also be adopted as an in-house standard by a project or
organization that decides to develop information for users in accordance with this document.
Organizations, projects, or multisupplier programs intending to claim tailored conformance should
consult ISO/IEC/IEEE 12207:2017, Annex A.
5 Information development process
The basic process phases as described in ISO/IEC 26514, such as analysis, design, development, and
review, still apply. However, agile practices eliminate the distinct separation of phases both within a
single iteration and across several iterations.
© ISO/IEC 2018 – All rights reserved
© IEEE 2018 – All rights reserved 3

The following agile practices affect the information development process:
a) Development in short iterations replaces long sequential process phases.
b) Information developers try to create accurate and complete information by the end of an iteration.
However, a review can lead to the development of additional information in later iterations.
Information developers receive training and practice to estimate and complete information for
users in time for the release of the iteration. Self-organizing agile teams replace formal roles and
contributions.
i) Software developers, testers, and team leaders may contribute to the analysis, design,
development, and review of information for users.
ii) Information developers may contribute to the design and test of the software as well as to
project artifacts and life cycle documents, such as user stories, use cases, and personas.
c) On agile projects, use cases and oral communication are used more frequently than formal
specifications and design documents.
i) Use cases, user stories, and personas clearly reflect the purpose and user benefit of each
feature.
ii) Demonstrations and peer reviews validate how development has achieved the intended
purpose and benefit.
iii) Information developers are embedded members of the agile team to promote efficient
communication and the quality of information deliverables.
d) Early, frequent feature shipments or releases replace scheduled release milestones. This means
that information deliverables should be part of the acceptance criteria of a complete functional
release or shippable increment.
NOTE For more information about designing and developing information for users in an agile environment,
see Clause 7.
Agile development is an iterative and incremental approach to development performed in a highly
collaborative manner by self-organizing teams. There are many specific agile development methods
that promote development iterations, teamwork, collaboration, and process adaptability throughout
the life cycle of the project. Agile development methods frequently discourage the creation of detailed
engineering support documentation and detailed technical specifications. This means that information
developers often do not have source documentation from which to extrapolate feature details.
The short time span of iterations means that the participation of each team member is essential. In
particular, unavailability of the information developer on the team may make it impossible for
information deliverables to keep pace with software development.
6 Management of information development
6.1 Change management for agile development
The information development lead or project manager shall decide, in consultation with the designers
and product managers, on the following:
— whether the information development team will follow agile development methods and integrate
with the development organization, or
— whether they will continue to operate using other methods. For example, some projects may use
agile development for the production of online help but not for printed information for users.
The information development team shall be educated on agile development practices before their
organization moves to the use of agile development methodologies. In addition, the information
© ISO/IEC 2018 – All rights reserved
4 © IEEE 2018 – All rights reserved

development lead, or project manager, or another appropriate member of the information development
team should be involved in defining what the new processes will be for the organization and negotiate
how agile development will affect their processes and team members.
The representative from the information development team should then communicate the plans to the
wider information development team and may facilitate their implementation.
6.2 Composition of agile development teams
6.2.1 General
An agile team is typically composed of an architect, developers, testers, information developers, user
representatives, and other stakeholders. In agile development teams, one individual may be expected to
perform multiple roles. For example, information developers may cover different roles and tasks such as
team facilitator, user interface designer, integration of user information with the product, testing, and
project tracking. This role sharing may depend on the requirements of the project or the availability of
resources.
The team member responsible for developing information for users should be skilled in conducting
user and task analysis, designing appropriate content deliverables for the identified users, conducting
reviews, and assessing information products with test participants.
If an information developer is unavailable, the information development lead or project manager should
decide the following:
— whether this team member will be replaced by another information developer from the information
development team or pool, or
— whether one of the other members of the agile development team will perform the information
developer role.
If another team member who is not an information developer by profession covers the information
developer role on the project, arrangements should be made to educate that team member in the skills
required and apply special attention to the peer review process.
6.2.2 Communication in agile development teams
Effective communication in an agile development team is key to the success of an agile development
project. Because the communication in agile development is real-time rather than through the use of
detailed life cycle documentation, information developers should participate in team meetings with the
other team members.
It is important to consider the difference between two distinct situations:
— a small, co-located team where the information developer(s) work daily and closely with the
development team, and
— a globally distributed team where two or more groups (of the same company or of different software
companies) are working together to produce different parts of a software package.
In the first case, all the agile principles and methodologies can be more easily applied. In the second
case, which is very common in large companies, there is sometimes an information development group
that is spread globally with some members assigned to different groups.
6.2.3 Globally distributed teams
For globally distributed teams, the application of agile principles may involve other considerations
such as:
— coordination of several information developers located across different development teams, and
© ISO/IEC 2018 – All rights reserved
© IEEE 2018 – All rights reserved 5

— logistic issues and communication challenges related to different time zones and different languages.
For these reasons, coordination processes should be provided for:
— addressing the communication challenges associated with a globally distributed team, and
— optimizing the workload of information developers according to the iteration schedule.
In this way, the information developers embedded in the different local development teams can facilitate
the implementation of agile principles with an approach that is more similar to a small co-located team.
When team members are not co-located, sufficient methods for establishing effective, efficient,
and reliable communication shall be put into place. These may include the following communication
methods:
— web-based video conferencing for meetings,
— teleconferencing for meetings, and
— one-to-one communication between the information developer and other agile team members.
While agile methods emphasize face-to-face conversation over written documentation, distributed
teams need more emphasis on written and formal communications.
The following may also be used to facilitate effective communication:
— collaborative document repositories such as wikis and databases,
— design/feature documents for sharing information,
— use case descriptions, and
— user stories.
When members of the agile development team work in different time zones or do not speak the
primary language of communication, special communication accommodations are needed. Temporary
assignment to the main location of the agile development team for remote team members may help
solve communication issues and establish better communication and relationships between team
members when the remotely-based team members return to their locations.
6.3 Management of information development across teams using agile development
In an agile development project, multiple teams may be working on different features of the software.
Information developers working on separate agile development teams may create different information
deliverables that do not fit together when the product is brought together as a whole. To address this
concern, the information development lead or the project manager shall make available standards at the
beginning of a project that are to be followed by all information developers for that project, including the:
a) information architecture that defines acceptable information elements such as topic types, their
structure, and their intended content,
b) style guide that defines conventions for language (such as tone, voice, mood), graphics (such as
file type, size, captions and callouts), and the user interface (such as references to windows, fields,
product functions), and
c) delivery formats such as web help or PDF.
The information development lead or the project manager shall allocate sufficient time shortly before
each release to consolidate the information for users so that it is consistent and free of contradictions,
gaps, and redundancies.
© ISO/IEC 2018 – All rights reserved
6 © IEEE 2018 – All rights reserved

6.4 Management of information development tasks across iterations
6.4.1 Planning the project as a whole
In a project using agile development, information for users is ideally developed in parallel and on the
same schedule as the software. This enables software to be regularly released to customers with
sufficient information for users. Providing the information for users as early as possible provides time
to review and test the information for users alongside the software.
Within each agile development team, a high-level overview of the planned software content of each
iteration should be developed. These plans are likely to be subject to change because new user
requirements can come into the project for inclusion in future releases at any time.
Development of information for users that relates to the product as a whole shall be included in the
planning by the information development lead or project manager who shall plan, schedule, resource,
and track these tasks as a part of the project. Ideally, these tasks are determined at the beginning of
the project in the project planning stage and are then allocated and drafted as early as possible in the
cycle. Planning for the project as a whole should include the minimum information requirements for the
product and the information for users.
In an agile environment, it can be difficult to produce detailed plans beyond a single iteration. However,
the project manager should produce a project plan that includes the iterations to be developed. The
iteration milestones should include software and information deliverables for manufacturing and
translation schedules.
The information development lead or project manager should reserve time before the end of a release
cycle for final production edits. The information development lead or project manager should set specific
freeze dates for the various artifacts related to information for users. The information development
lead should determine how much information for users is required and the minimum requirements for
the inclusion of task, concept, reference, and troubleshooting information for the content to be usable
and ready for release to customers.
Not all information development work will necessarily take place in a single iteration; for example, work
related to an information architecture strategy may need to be completed over multiple iterations.
Tasks that fit into the bigger picture need to be considered and planned in addition to tasks defined
for the individual iterations. Some tasks can be performed in special iterations or at other points in
a project’s life cycle that can have an impact on the information for users; for example, acceptance
test, translation, and accessibility testing. There can also be iterations that focus on consolidation or
infrastructure tasks not requiring concurrent information development.
There are different information delivery models depending on the team's resources and the
organization:
— For teams with dedicated information developers, the information for users can be released in
parallel with the software.
— For organizations that have centralized information developers who are tasked with supporting
multiple development teams, more formal and structured approaches such as setting a freeze date
are more feasible.
— A hybrid approach is also possible, where an information developer drafts the information roughly
in parallel with software development, but has a freeze date at the end of the project to complete
and deliver the information for users.
There can also be information development work that needs to be performed but that is not associated
with a software feature produced by an agile development team.
Some types of information can be difficult to develop in individual iterations, especially content
related to the project as a whole. Examples of information for users that relate to the project as a whole
may be installation and configuration guides, tutorials, high-level concepts, reference material, and
© ISO/IEC 2018 – All rights reserved
© IEEE 2018 – All rights reserved 7

troubleshooting information. It may be possible to schedule the development of these information
items at the beginning of a project between the acquisition of requirements and the start of software
development, sometimes known as iteration zero, or during iterations dedicated to testing or quality
assurance. The information for users that is produced for these items should be reviewed at the end of
the iteration and considered if any changes occurred during the iteration.
The project planning components to develop information for users in an agile project are described in
the following subclauses of this document.
6.4.2 Sizing and resourcing each iteration
6.4.2.1 General
Planning for the project requires planning the content for individual iterations. The information for users
produced with the product functions in each iteration is likely to be mostly task-oriented information,
although it can also be possible to schedule feature-related concept and reference materials within the
individual iterations. Planning for each iteration should include the identification of tasks based upon
the features to be completed within that iteration. Development of concept and reference materials can
be easier to schedule at the beginning of an iteration, while task-based information may be easier to
develop after coding or prototypes have been completed.
Planning for each iteration should include tasks for information development:
— research activity,
— familiarization with the application and how the user would use it,
— adequate review of content, structure, and style, and
— testing of the information for users.
The information developer, information development lead, or project manager should plan for and
determine that the details and sizing for the information development work — including user stories,
features, and backlog — are included in the plan for each iteration. The information developer,
information development lead, or project manager should plan and schedule the required time and
resources so that they are included in the iteration length and work item sizing to cover the review, test,
and editing of the information.
Time should be provided for testing of the information with the working software, but it can be
appropriate to schedule this testing in a separate iteration. Time for updates to the information for users
as a result of defects or problems found during review and test should also be included in the plans.
Sometimes it is not practical to provide complete and thorough information for users for a software
feature developed in a single iteration. Therefore, planning the information for users to accompany the
software feature should focus on the most essential information required to support the user. In some
agile development teams, planning includes core and stretch items. Instructional information that
is required for the user to be able to use the software shall be part of the core items, but supporting
information such as overviews and concept documents can form part of the stretch items. The core
items should be created as a priority and any agreed items that are not completed shall be carried over
into the next iteration. In this case, the planning of the next iteration shall consider the related impact.
6.4.2.2 Sizing information development work
The information development lead, project manager, or information developer should size the
information development tasks based on estimates from previous development activities, considering
the potential for reuse or adaptation of existing material.
NOTE The complexity of the software development effort does not directly relate to the time and amount of
detail required in the information for users. The need for information creation can vary widely between teams
and iterations. For instance, one team can do back-end refactoring for two iterations with minimal effect on the
information for users.
© ISO/IEC 2018 – All rights reserved
8 © IEEE 2018 – All rights reserved

Depending on the iteration, the information developer should break down large tasks into smaller tasks.
Tasks that are sized for more than five days can be difficult to estimate adequately in an iteration, and
can result in slippage if the task cannot be completed in the iteration. For short iterations―for example,
one or two weeks―tasks sized at over one day should be broken down into smaller tasks.
The information developer shall document and plan for any agreed items that are not completed. These
items are carried over into the next iteration. A function is not done until:
— software coding has been completed,
— information for users has been completed,
— both software and information for users have been tested, and
— any issues identified from testing have been resolved or a plan exists to resolve them.
6.4.2.3 Assigning information development resources
In an ideal agile environment, the information deliverables for each user story are completed in the
same iteration as the development and testing work. The information development lead or project
manager shall list and size the information development tasks before the start of each iteration. If the
estimates exceed the resources for the iteration, the information developer should coordinate with the
team to prioritize the tasks and, if necessary, schedule the overflow for the following iteration.
In some projects there is a single agile development team, and in others the
...