The current issue and full text archive of this journal is available on Emerald Insight at:

https://www.emerald.com/insight/1754-2731.htm

An evaluation of documentation Documentation

requirements
requirements for ISO 9001 for ISO 9001

compliance in scrum projects

Anuradha Mathrani
School of Natural and Computational Sciences, Massey University,
Auckland, New Zealand Received 11 August 2020
Revised 9 December 2020
Shanuka Wickramasinghe 4 February 2021
24 March 2021
Massey University, Auckland, New Zealand, and 8 April 2021
13 April 2021
Nihal Palitha Jayamaha Accepted 14 April 2021
School of Food and Advanced Technology, Massey University,
Palmerston North, New Zealand

Abstract
Purpose – Quality management standards (e.g. ISO 9001) lead to process conformance in the realization of
quality goods and services; however, they can be rather document intensive. This paper investigates
documentation practices used for aligning “light-weight” Scrum methods with ISO 9001 in a leading healthcare
software firm.
Design/methodology/approach – The authors investigated how “light-weight” Scrum approaches fit with
organizational documentation practices for ISO 9001 compliance in one leading healthcare software
development firm. Three investigative rounds were conducted with software professionals having different
Scrum roles to understand their challenges in maintaining process documentation with Scrum methods.
Findings – ISO standards stipulate certain mandatory documentation as evidence that certain pre-defined
processes are followed in the build-up of quality goods and services. However, this may result in “heavy-
weight” document driven approaches that interfere with “light-weight” Scrum methods. Case study findings
reveal tensions faced by software professionals in maintaining the ISO 9001 documentation. That is, while
some level of documentation is considered useful, software professionals consider certain other documentation
tasks to be excessive and cumbersome. Further, many operational documents were written retrospectively for
administrative compliance, leading to reduced, incomplete and ambiguous descriptions.
Practical implications – The study provides much value for practitioners in adapting their documentation
with ongoing operational processes. Further, the critique on current ISO 9001 implementations in Agile
environments has implications for future documentation practice.
Originality/value – The empirically drawn findings showcase some of the challenges in maintaining ISO
9001 documentation within Scrum projects. The study has contributed to both theory and practice in relation to
the co-existence of ISO drawn standards with Agile approaches used for software development.
Keywords Quality management systems, ISO 9001 standard, Scrum, Documentation,
Quality assurance, Agile
Paper type Research paper

1. Introduction
Agile approaches are acknowledged as a growing industry trend in software development for
small- and large-scale projects. Software professionals wear technical and creative hats
alongside business hats as they manage change to their software designs with agility, while
at the same time responding to formal work processes. Formal processes are prescribed to
help identify current market demands, manage risks of overruns and streamline efforts in
conforming to product quality standards. But in doing so, formal processes promote some
The TQM Journal
The authors would like to thank both the anonymous reviewers for their constructive feedback. Their © Emerald Publishing Limited
1754-2731
insightful reviews have helped in improving the quality of the reporting immensely. DOI 10.1108/TQM-08-2020-0177
TQM form of “policing”. Consequently, a mix of “creative” and “policing” strategies are required to
maintain quality assurance (QA) of both the product and the process. Customers expect good
value from their software purchases (Stoica et al., 2013), and quality cannot be a hit-or-miss
proposition (Everett and McLeod, 2007). But, bringing about reliable high-quality software
within short incubation times poses many challenges to corporates. Traditional methods
focus on document intensive change management practices; hence, are considered “heavy-
weight” that lead to more “policing” and in turn reduce “creativity”. However, practice
experiences have made corporates realize that they cannot ignore the term “soft” in
“software” (Mathrani and Mathrani, 2013), and agile methods have become the new norm
(van Waardenburg and van Vliet, 2013; Dikert et al., 2016). Agile is a generic umbrella term for
“light-weight” approaches, including extreme programming, Scrum, adaptive software
development, Crystal, feature driven development and others. These promote agility and
encourage developers to accept unexpected changes and re-think their designs. Scrum is a
widely recognized agile approach that focusses on project management viewpoint; it
envelops responsiveness, review and rework within short turnaround times to help meet
project deadlines. That is, Scrum provides the ability to effectively manage change as the
software evolves with functional and non-functional add-ons. However, quality issues in
Scrum, especially process issues that are people-related such as employee skills, motivation,
etc. are under studied in the existing literature (Mishra and Abdalhamid, 2018).
Business usually have some quality management system (QMS) in place. The QMS
comprise resources (e.g. people, hardware, software and processes), reporting structures,
work policies and defined objectives for efficiently enabling the design, development,
delivery and maintenance of the product (Leung et al., 2007; Summers, 2018). Currently, ISO
9001 is one of the most widely recognized quality standard (Hooper, 2001;
International_Organization_for_Standardization, 2019; Chiarini et al., 2019). ISO 9001 sees
the organization as “manageable and controllable units which can be used by management as
instruments for fulfilling predetermined goals, strategies and visions” (de Vries and
Haverkamp, 2015, p. 20). Accordingly, it stipulates certain mandatory documentation as
evidence to assure their management that its employees (or software professionals engaged
in Scrum projects) are following standardized processes in the build-up of quality goods and
services. Auditors inspecting ISO 9001 compliance require additional documents which
describe actions being taken for implementing the standard. Agreement to comply with ISO
9001 requires the organization to generate high-level QA documents (e.g. quality manual,
quality policy and quality objectives) as well as at operating levels (e.g. quality procedures
and quality records). Unfortunately, this may drive organizations to “heavy-weight”
document-driven approaches that conflict with the autonomy of agile approaches.
Management standards affect human behaviour more than technical standards and could
result in tensions between control and freedom (de Vries and Haverkamp, 2015). In other
words, employees often consider documentation as “unwelcome, unnecessary, and harmful
intrusion” that is a form of policing which interferes with their creativity (p. 19). Hence, there
exists some tension between the “freedom” offered via Scrum with “control” from an ISO-
9001-based quality standard.
To the best of our knowledge, no studies have examined documentation requirements of
ISO 9001 implementation in relation to “light-weight” agile methods. Prior studies on
compatibility between ISO 9001 and agile software approaches (e.g. (McMichael and
Lombardi, 2007; St
alhane and Hanssen, 2008; Qasaimeh and Abran, 2013)) have been
confined to conceptual level arguments. This study undertakes an in-depth case study
investigation on ISO 9001 documentation alignment with Scrum-based projects. Having
posed the intent of this study, the following section lays out the research questions, which is
followed by an overview of Scrum and the ISO standard series. Next, research methods used
for this investigation are described, followed by a description of the case where the
investigation took place. We further elaborate on documentation strategies used by software Documentation
professionals and their perceptions on ISO 9001 document upkeep with “light-weight” Scrum requirements
methods. We draw upon practitioner experiences to answer the research questions. Finally,
the conclusions and limitations are presented, which provide a background lens for
for ISO 9001
conducting future research.

2. Research questions
Documentation is a fundamental aspect in any audit in general and ISO 9001 compliance in
particular; therefore, we queried software professionals on how “light-weight” Scrum
approaches fit with their organization’s guidelines for ISO 9001 compliance. Specifically, we
aim to understand motivation levels among professionals in creating quality compliance
documents, and how it impacts their learning and QA process improvements. Following two
research questions are posed:
RQ1. What level of documentation should be adopted in Scrum projects for maintaining
ISO 9001 compliance?
RQ2. How are current ISO 9001 documentation requirements for Scrum projects
perceived by software professionals?

3. The Scrum methodology

Agile methods emphasize iterative, evolutionary and incremental software development
methods rather than traditional “simplified single-pass and document-driven” methods
(Larman and Basili, 2003, p. 55). Scrum is a “light-weight” process framework under the agile
software framework that comprises three categories, namely roles, deliverables and meetings
(refer Table 1). First, the Product Owner (PO) prepares an ordered list of items called Product
Backlog (PB). High-priority items in PB are broken into smaller deliverables by Scrum Teams
(ST) and the Scrum Master (SM) during the sprint planning session (SPS). SM and ST hold

Roles Product Owner (PO) PO sets priorities in project tasks as have been documented in PB.
PO is responsible for business value
Scrum Master (SM) SM enables close cooperation amongst the ST to maximize business
value
Scrum Team (ST) Cross-functional team members (5–9 members) organize their work
for each sprint (of 2–4 weeks)
Deliverables Product Backlog (PB) PB is a list of items/features prioritized by business value. The high-
priority items are broken into appropriate detail
Sprint backlog (SB) SB contains highest-priority items/features from the PB that are to
be completed in a sprint
Burndown chart (BC) BC is a graphical display showing progress of each sprint. It helps
PO identify at-risk items or consider extra items to be added to SB
Meetings Sprint planning SPS is conducted to select work items from PB to deliver during a
session (SPS) sprint
Daily Scrum (DS) DS is a short meeting where ST share their progress/challenges and
plan work for the day
Sprint reviews (SR) The ST informs PO during SR on tasks completed during the sprint. Table 1.
The PB is updated for the next sprint cycle Scrum components
Sprint retrospectives SRR is conducted after SR to reassess the sprint’s progress and (Schwaber and
(SRR) report on lessons learned. The PO decides on updating PB based on Sutherland, 2013;
report Schwalbe, 2019)
TQM Daily Scrums (DS) where day-to-day deliverables using the high-priority items listed in the
sprint backlog (SB) are planned. A burn down chart (BC) provides graphical display of
progress made in the sprint. During sprint reviews (SR), the ST demonstrates tasks that were
completed during the sprint and which have been validated by the PO. Lastly, a sprint
retrospective (SRR) occurs after the SR, but prior to the next sprint. Here teams’ reflect over
the lessons learned. Action points from SRR feedback are presented to the PO. The PB may
get updated if PO considers the feedback has provided some business value.
Scrum is organized in a manner which is attractive to software developers because of the
“structured freedom” and teamwork it provides. By optimizing turnaround time and
demonstrating responsiveness to fast-changing market requirements, Scrum applies
iterative and incremental practices for ensuring quick product releases are delivered to
customers. Moreover, if any feedback is provided by the customer on seeing the product
demo, the product is tailored accordingly in subsequent sprints (Mishra and Abdalhamid,
2018). In this manner, Scrum projects have focus on the customer which assists in achieving
higher customer satisfaction rates.

4. The ISO series

The ISO series have received much recognition as a QMS and are widely discussed in
scholarly research. The series comprise three components: (1) fundamentals and vocabulary
(ISO 9000), (2) QMS requirements for certification/ compliance (ISO 9001) and (3) guidelines
for performance improvement (ISO 9004 which by itself is not a certification standard, rather
supplements ISO 9001). Over the last couple of decades, the ISO 9001 framework has evolved
with cumulative knowledge derived from engineering, management sciences, social sciences
and behavioural sciences (Hussain et al., 2020) and resulted in increased ISO 9001
certifications worldwide (https://www.iso.org/the-iso-survey.html). ISO 9001 was first
introduced in 1987. Since then it has undergone periodic revisions in 1994, 2000, 2008 and
the last one in 2015 (https://www.9001council.org). The first version laid emphasis on
standardization of activities through formulation of procedures, while the second version
added emphasis to defect prevention rather than just evaluation of the final product. The
third version introduced process management concepts which were further reinforced to
better align with ongoing organizational activities in the next version (Sfreddo et al., 2018).
The latest version (i.e. ISO 9001:2015) is substantially different from its predecessors since it
brings in concepts related to risk assessment, organizational context and leadership roles
(Sfreddo et al., 2018); however, its “auditability” is not without challenges (Domingues et al.,
2019). Dominigues et al. advise auditors to provide an independent perspective that does not
follow the conventional clause-based auditing process of the previous standard.
Much of the ISO 9001 scholarly research is limited to manufacturing, where several
authors have argued in favour of the standards, while several others have highlighted their
drawbacks (e.g. (Manders, 2014; Santos et al., 2016; Murmura and Bravi, 2017; Tomic and
Brkic, 2019). Chiarini et al. (2019) call upon the committee to consider both favourable and not
so favourable criticism in their next revision of the ISO 9001 standard. The standard contains
specific clauses for establishing, reviewing, communicating and improving QA practices
with all stakeholders (Hussain et al., 2020). Much of the quality concepts upon which ISO 9001
hinges are drawn from Edwards W. Deming’s PDCA cycle (i.e. plan-do-check-act-[repeat])
(Summers, 2018). The PDCA cycle builds an incremental part of a continuous improvement
process that aims at improving the overall quality standards (Saier, 2017). First, we establish
some process (plan), then the process is executed (do), after which outcomes are measured
(check). These outcomes are assessed for future improvements (act) and accordingly the
PDCA cycle may start again. The four steps of the PDCA cycle are covered in a high-level
structure (comprising clauses and subclauses) and form an integral part of the ISO 9001
standard (Murray, 2016). Based on tangible documented evidence provided in these clauses/ Documentation
subclauses, auditors are informed on the quality compliance imperatives across the requirements
PDCA cycle.
While agile methods lay emphasis on less documentation, “in reality a mix of agile and
for ISO 9001
structured practices” (Daneva et al., 2013, p. 1338) is often used. A QA perspective requires
certain level of explicit documentation that acts as a baseline and indicates commitment to
continually improve processes in compliance with the QMS. The extent of documentation
used for describing associated processes depends on the organization’s culture and product
type (International_Organization_for_Standardization, 2016). Large software organizations
are known to be quite explicit about QA practices that they employ (Mathrani and Parsons,
2012). Further, the degree of formality in organizational reporting (e.g. bureaucracy and
signing authority) influences the documentation presentation style (St
alhane and Hanssen,
2008). Since no fixed reporting format is prescribed, all documents must be carefully reviewed
to ensure readability before they are added to the repository or submitted to auditors of the
accreditation agency. Having a common document format with detailed comments by the
reviewer and other stakeholders (after each revision) is beneficial for subsequent revisions
(Myhrberg, 2009). Organizations usually establish a template for various processes used in
PDCA cycles. These templates provide a useful framework for specifying requirements,
reporting progress, monitoring business flows, confirming deliverables and communicating.
However, the process documentation is often overstated, especially for Scrum projects, which
mainly rely on face-to-face communication during daily stand-ups and sprint retrospectives
(Hanssen et al., 2018). This has made some practitioners question if the practice of
maintaining documentation outweighs their potential benefits (R€ ueping, 2003; Zhi et al., 2015;
Klute-Wenig and Refflinghaus, 2020).

5. Research methods
Case studies are especially relevant in the software engineering area since they provide a real-
world organizational context for investigating complex wide ranging interactions that occur
among technologies, people and projects (Runeson et al., 2012). In this study, we investigated
documentation practices for ISO 9001 compliance for a leading healthcare software
development organization (Health-IT [1]) by engaging with key personnel working in Scrum
environments. The study embraces two contextual areas: (1) Scrum methodology in the
healthcare software development field and (2) ISO 9001 certification in the field of quality
systems. Yin (2013) suggests using data source and methods triangulation so as to span
different contexts and collect overlapping data for strengthening internal validity, increasing
confidence in the finding and establishing generalizability. Practitioners having different
Scrum roles (i.e. PO, SM and ST) participated in this study over three investigative rounds to
provide data source triangulation. Each investigative round was exclusive. Participation by
all software professionals was voluntary. Further, the enquiry mainly aimed to understand
their perspectives in regard to Scrum alignment with ISO 9001 documentation; hence, no
personal or demographic data were collected from participants. Method triangulation
involved a combination of quantitative and qualitative methods that encompassed both
contextual areas and provided plurality of meanings to assist in addressing variations and
making generalizations (Larsson, 2009).
Three investigative rounds were conducted as follows. Round-1 adopted an open-ended
enquiry to track all documents being used in Scrum projects. We also examined professional
job positions alignment with Scrum roles. Round-1 gave us some insight on documentation
and professional positions across Scrum projects. In round-2, we asked Scrum professionals
to rank the usefulness of each document based on their role. Next in round-3, participants
were queried on the relevance of each document (e.g. format and content). Multiple data
TQM sources (i.e. professionals having different Scrum roles at Health-IT) facilitated empirical data
collection over multiple rounds (Daneva et al., 2013) and permitted a robust and deep case-
oriented analysis. Moreover, the sample was representative of the population under
consideration (Boddy, 2016) since all participants had some experience with ISO 9001
documentation practices in “light-weight” Agile project environments.

6. Case description and research setting

Healthcare software is developed for clinicians, practitioners and patients. Maintaining
patient privacy, security and confidentiality is a high-priority task; therefore, health-related
technology applications need more careful evaluation compared to applications for other
fields (Sligo et al., 2017). The healthcare software is based on complex lengthy standards and
specifications; these ensure that all development team members are aware of the underlying
complexities and guide agencies in maintaining a subset of documents that contain important
(or critical) conformance requirements (Cellucci et al., 2011). By keeping records of
development, testing and other validation tasks that have been undertaken, software
teams stay on track with the ongoing developments. Further, routine documents such as user
manuals are maintained for end-users (e.g. for doctors, clinical staff, patients and the
administrative staff) (Chen, 2013). User manuals lay out instructions for installation,
evaluation, operation, use and maintenance, which influence the end-users perception of the
product quality and their satisfaction judgement (G€ok et al., 2019).
The study was conducted in a healthcare organization in Auckland, New Zealand
(henceforth referred as Health-IT). Health-IT develops software that handles sensitive
personal health information records of patients. Their software is used by registered medical
doctors and administrative staff at government hospitals, blood banks and insurance
agencies. Since development teams are privy to sensitive information, many privacy and
security measures are laid by Health-IT for safe-keeping of patients’ personal information.
The management is internally motivated to implement ISO 9001 for performance
improvements rather than for certification purposes (Santos et al., 2016). de Vries and
Haverkamp (2015, p. 20) voice that future studies should take account of employee motivation
to understand “tension between control and freedom” in QMS implementations. This study
evaluates ongoing tensions between control (as a consequence of standardization) and
freedom (or employee autonomy) while implementing ISO 9001 in Scrum projects. The study
participants included software professionals in different Scrum roles (e.g. product owners,
Scrum masters, technical writers, developers, testers and business analysts). Our objective
was to examine tensions when professionals have to balance the seemingly conflicting
documentation requirements of “light-weight” Scrum activities with formal ISO 9001
standards. The ISO 9001 standard stipulates some mandatory high level (strategic level)
documents (e.g. the quality manual, quality policy and quality objectives), while the
operational-level documentation is less rigid. At most, the operational documents must
convey the quality worthiness of the candidate organization to the auditor assessing it for
quality compliance (Poksinska et al., 2006; Wealleans, 2017). Auditors rely on documented
evidence; therefore, having more documents can often serve as an assurance against any
indecisiveness that may arise if less information is made available to auditors
(Wealleans, 2017).
The first round of investigation was conducted with five participants, who along with one
of the authors conducted an inspection of the QMS documentation. A total of 23 documents
were suggested. Scrum roles based on professional job positions were also noted. In the
second round, separate face-to-face meetings were held with 18 participants, who evaluated
the 23 documents (obtained from the first round) with Scrum roles. Five scales ranging from
“extremely relevant” to “not relevant at all” were set. The content of documents considered
relevant to Scrum were queried next. Finally, in the third round, nine participants (each of
whom had previously taken on roles of PO, SM or ST) were queried on templates used in the Documentation
23 documents. Participant perspectives on level of documentation considered to be apt, and requirements
issues faced in documentation preparation were noted. Table 2 describes the participants and
the questions that were posed in each round.
for ISO 9001

7. Responses from the three rounds

The objective of the study was to determine (1) the critically important documents that are
required to (seemly) meet the documentation requirements of ISO 9001, (2) the content that
should be included in each document and the stage of the Scrum project when each document
is prepared and (3) the issues surrounding the documentation processes in Scrum projects.
Following subsections present the results of each round.

7.1 Round-1:
The objectives of round-1 were twofold: (1) to identify documents perceived to be relevant in
Scrum projects and (2) to relate job positions with Scrum roles. Round-1 participants listed 23
documents through consensus decision-making. Table 3 lists the 23 documents with brief
descriptions explaining the purpose of each document.
Next, participants aligned professional job positions across different functional areas with
the three Scrum roles (i.e. PO, SM and ST). Table 4 lists job positions aligned with their
Scrum roles.

Round Participants Questions that were posed

Round- Participants 5 5 (Job positions: development
1 team leader, project manager, solution
architect, test engineer and QMS executive)
Round- Participants 5 18 (Job positions: development
2 team leader, business analyst, test engineer,
QMS team member, technical writer, customer
support engineer and implementation
consultant)
Round- Participants 5 9
3 All participants held one of the 3 Scrum roles
(i.e. three participants served as PO, three
served as SM and three served as ST)
Two open-ended questions were posed at the
first stage
(1) Which documents are used in Scrum
projects?
(2) What Scrum roles are allocated to which
software professionals?
Based on round-1 responses, two questions were
posed
(1) From the above list, which documents are
considered useful to maintain for good
cross-functional communication on a day-
to-day basis?
(2) Rank the usefulness of all the documents
provided in the list for various Scrum roles
(on a scale of 1–3 where 1 5 very useful,
2 5 useful and 3 5 not useful)
A list of documents (based on Round-1 and
Round-2) with sub-headings of clauses in each
document was presented
Four open-ended questions were posed
(1) From the list of documents, which headings
are considered important for the PO, SM
and ST roles?
(2) When are these documents prepared in a
Scrum project? Table 2.
(3) Please state any issues you had in Details of the three
completing these documents investigation rounds
TQM Doc_ID_01 Maintained product backlog: An ordered list of requirements that might be needed in the product
Doc_ID_02 International specifications: The industry requirements and world-wide industry standards are
stated (e.g. IHE, HL7 and FHIR)
Doc_ID_03 Standards and regulations: Based on the product and target market, relevant industry standards
and regulations are listed for PO. (e.g. electronic health products sold in the US since 2013 have a
MU2 (Meaningful Usage 2) certification stipulated by USA federal government)
Doc_ID_04 Stakeholder/customer requirements: The needs and expectations of customers/stakeholders who
can be external users or internal customers (e.g. colleagues within the same organization who
depend on the team) are specified
Doc_ID_05 Business flows: Illustrates the start-to-end processes that take place in a business. Business
Process Model and Notations (BPMN) notations are used to depict business process flows
Doc_ID_06 Road map items: Is a plan derived from the product backlog to match short-term and long-term
product goals with specific solutions (e.g. user stories/features) and time-line schedules. Also
referred as “epics” in some organizations
Doc_ID_07 Features: Are the smallest units of work. They are also referred to as user stories
Doc_ID_08 Test verification report: After developing a feature, it is passed for testing purposes. Testers
produce a report (containing manual and automation test scripts, test results and supportive
documents such as screen shots) for that feature. This report is linked to the feature so that
verification notes can be traced
Doc_ID_09 Sprint demonstration recordings: At the end of the sprint, the ST conduct demos of the completed
“feature work”, engage with other stakeholders and clarify any questions posed. These
engagements are recorded and retained by the organization
Doc_ID_10 Retrospective notes: The SRR meeting offers an opportunity for the ST to understand the
processes which worked or did not work. Teams discuss issues and self-organize their work
towards resolution of issues in the next sprint. Maintaining notes of each retro meeting is
considered helpful to see how the team overcame problems
Doc_ID_11 Training material: Online documents are provided to internal staff, so they can learn about new
products or new practices
Doc_ID_12 Risk analysis reports: For facilitating understanding of the risks and providing suggestions on
risk mitigation activities
Doc_ID_13 Technical design: The overall product design which has been reviewed by technical experts
Doc_ID_14 Database designs: Documentation on data models that are used in the product
Doc_ID_15 Developer documentation: Developers maintain documentation of their individual modules
Doc_ID_16 Requirements traceability matrix: Provides an overview to help in identifying coverage gaps in
requirement gathering and verification
Doc_ID_17 Unit test and test reports: Comprise individual code units for testing a function. These reports are
useful for understanding code coverage and test coverage
Doc_ID_18 Source code files: Comprises the “source” of the program (e.g. variables, parameter assignments,
loops, etc.)
Doc_ID_19 Bug tickets: Are pre-defined labels to reports on bugs (or incorrect functionality)
Doc_ID_20 Test plans: Shows the planned verification activities. Prepared at early stage of development
Table 3. Doc_ID_21 Bug verification report: Includes information (e.g. errors, screenshots) about tests that failed
List of ISO 9001 Doc_ID_22 User manuals: Provide useful guidance so that customers can use products on their own
documents that have Doc_ID_23 Companywide quality procedures: Quality procedures are very dynamic due to international
some relevance in regulations and market changes. This document provides a holistic view of quality procedures.
Scrum projects In case of major change, staff may request awareness training

7.2 Round-2
This round comprised 18 participants, namely, one PO, two SMs and fifteen ST members.
Each participant shared their perception on the degree of usefulness of each document with
their role. Table 5 shows the degree of usefulness of the 23 identified documents for different
Scrum roles. The PO considered nine documents to be very useful and eight documents to be
somewhat useful, while both SMs considered eight documents to be very useful and eight
documents as somewhat useful. Aggregated responses from the 15 ST members show 13
documents to be very useful and seven documents as somewhat useful. It is not surprising
that documentation on “Training Material” (Doc_ID_11) did not show up as a relevant or as a
Product owner Scrum master Scrum team
Documentation
requirements
(1) Any person holding a high authority position (1) Project (1) Technical Lead for ISO 9001
(e.g. strategic project manager) manager (2) Developers
(2) Customer/stakeholder (2) Team leader (3) Testers
(3) Business (4) User interface developers
analysts (5) Technical writers
(6) Implementation
consultants
(7) Customer support Table 4.
engineers Categorization of
(8) Quality assurance team professionals with the
members main Scrum roles

Degree of usefulness
Document ID Document PO SM ST

Doc_ID_01 Maintained product backlog ** **

Doc_ID_02 International specifications ** ** *
Doc_ID_03 Standards and regulations ** ** *
Doc_ID_04 Stakeholder/customer requirements ** ** **
Doc_ID_05 Business flows ** ** *
Doc_ID_06 Road map items ** * *
Doc_ID_07 Features ** ** **
Doc_ID_08 Test verification report * * **
Doc_ID_09 Sprint demonstration recordings * * *
Doc_ID_10 Retrospective notes ** **
Doc_ID_11 Training material
Doc_ID_12 Risk analysis reports ** **
Doc_ID_13 Technical design * * **
Doc_ID_14 DB designs **
Doc_ID_15 Developer documentation **
Doc_ID_16 Requirements traceability matrix * * *
Doc_ID_17 Unit test and test reports **
Doc_ID_18 Source code files **
Doc_ID_19 Bug tickets * * **
Doc_ID_20 Test plans * * **
Doc_ID_21 Bug verification report * **
Doc_ID_22 User manuals **
Table 5.
Doc_ID_23 Companywide quality procedures * * ** The degree of
Note(s): *Indicates a Useful document based on the votes received usefulness of each
**Indicates a Very Useful document based on the votes received document with
No asterisk (*) indicates being Not Useful, based on the votes received different Scrum roles

useful document since it is not directly related to project tasks. All other documents held some
level of significance across the different Scrum roles.

7.3 Round-3
Round-3 participants comprised three POs, three SMs and three ST members. We asked
participants which aspects of the document adequately aligns with the ISO 9001 standards,
and also the stage in Scrum projects when the documents are created/updated. Lastly, we
wanted to know about issues faced in completing the documentation.
TQM 7.3.1 Documentation relevance in scrum projects. Documents are created throughout the
life of Scrum projects; therefore, Health-IT used a common format in reporting style among
technical and business professionals. All QMS documents used a standard template
comprising a general section and a content section (Table 6). Health-IT viewed that enforcing
a uniform document layout brought order and simplified tasks for all their stakeholders (e.g.
employees, customers and auditors).
Table 7 indicates that PO and SM consider the admin related aspects of the general
section, such as, “Author”, followed by “Purpose” and the “Sign off by Approvers/Reviewers”
relevant. Further, in the content section, POs expressed interest in “Flow charts/diagrams”,
followed by “Verification and validation information”, while SMs revealed interest mainly in
“Verification and validation information”. For Scrum teams, the most relevant general
sections comprise “Purpose”, followed by “Sign-off by Approvers/Reviewers”, while
“Corrective” and “Preventive” action records are least relevant. ST members mainly refer
to “Development instructions” and “Verification and validation information”, while “Flow
charts/diagrams” are least referred. Based on participant rankings, 10 documents are
appropriate (i.e. all sections are mostly referred), five documents have some redundancy (i.e.
some sections are not referred), while eight are excessive (i.e. many sections are not referred).
Figure 1 shows the stage in Scrum projects when each document is produced or updated.
Project initiation stage is the stage when the software development work is started.
Professionals require information from product backlog, standards and regulations,
international specifications, stakeholder requirements and quality procedures at this stage;
hence, these documents are created at the project initiation stage. Once the project is finalized,
the ST decide on the scope of their work and the number of sprints required. Documents such
as the product backlog, standards and regulations, international specifications, stakeholder
requirements, quality procedures, business flows, road map, features, technical and database
designs and test plans are required at the starting stage of a sprint.
Within the sprint, Scrum teams further create the user manual, source code files, bug
tickets, test verification report, unit tests and developer documentation. Near the end of each
sprint, demo recordings, retro notes complete with bug verification notes, unit tests and risk
analysis reports are created by ST members. After multiple iterations, when the product is
completely ready for production, the teams create training materials, traceability matrices
and risk analysis notes. After the release, depending on the product, the development team
still maintain the risk analysis reports. The bug tickets can be created by any member who is
engaging with the software at any stage of development, as it concerns product quality.
7.3.2 Issues with documentation. Lastly, the third round examined issues related with
documentation in typical Scrum environments. Concerns raised by POs included the
technical nature of final documents that were finally released since POs were of the view that
such technicalities are not understood by the end-user/customer. On the other hand, SM and
ST were of the view that non-technical professionals missed the picture and trivialised the
hard work done by the technical staff.

General section (fixed) Content section (variable)

(1) Purpose (1) User stories

(2) Author (2) Flow charts/diagrams
(3) Sign off: Approvers/reviewers (3) Development instructions
Table 6. (4) Internal communication records (4) Release schedules/notes
Format for the 23 (5) Corrective action records (5) Known issues
documents stipulated (6) Preventive action records (6) Verification and validation information
by ISO 9001 standards (7) Comments on validity: out-of-date/relevant
 Documentation
Doc ID Roles General Section Contents Section Relevance to roles &
Documentation level
requirements
1 2 3 4 5 6 7 a b c d e f
Doc_ID_01 PO ; ; ; ; ; ; ; • All roles for ISO 9001
(Maint. prod SM ; ; ; ; ; ; ; ; • Some redundancy
backlog) ST ; ; ; ; ; ; ; ; ;
Doc_ID_02 PO ; ; ; ; ; ; ; • All roles
(International SM ; ; ; ; ; ; • Appropriate
specs) ST ; ; ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_03 PO ; ; ; ; • All roles
(Stds & reg.) SM ; ; ; ; ; ; • Some redundancy
ST ; ; ; ; ; ; ; ;
Doc_ID_04 PO ; ; ; ; ; ; ; ; • PO & SM
(Stakeholder SM ; ; ; ; ; ; ; ; • Some redundancy
reqts) ST
Doc_ID_05 PO ; • SM & ST
(Business SM ; ; ; • Excessive
flows) ST ; ; ; ; ;
Doc_ID_06 PO ; ; ; ; ; ; ; ; • PO & SM
(Road map SM ; ; ; ; ; ; ; ; • Some redundancy
items) ST ; ; ; ;
Doc_ID_07 PO ; ; ; ; ; ; ; ; • PO & SM
(Features) SM ; ; ; ; ; ; ; ; • Appropriate
ST ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_08 PO • SM and ST
(Test verif. SM ; ; ; ; ; ; ; ; ; • Appropriate
rpt) ST ; ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_09 PO ; ; ; • SM and ST
(Sprint demo SM ; ; ; ; ; ; • Excessive
recordings) ST ; ; ; ; ;
Doc_ID_10 PO • SM and ST
(Retro notes) SM ; ; ; ; • Excessive
ST ; ; ; ; ;
Doc_ID_11 PO • ST
(Training SM • Excessive
material) ST ; ; ; ;
Doc_ID_12 PO ; ; ; ; ; ; ; ; ; ; ; • PO & SM
(Risk analysis SM ; ; ; ; ; ; ; • Appropriate
reports) ST
Doc_ID_13 PO ; ; ; ; ; • ST mainly
& 14 (Tech. SM ; ; ; ; ; ; ; • Appropriate
& DB design) ST ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_15 PO • ST
(Dev. doc.) SM • Appropriate
ST ; ; ; ; ; ; ; ; ; ;
Doc_ID_16 PO ; ; ; ; • All roles
(Requirement SM ; ; ; ; • Excessive
trace matrix) ST ; ;
Doc_ID_17 PO • ST
(Unit tests & SM • Appropriate
test reports) ST ; ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_18 PO ; ; ; • ST
(Source code) SM ; ; ; ; • Appropriate
ST ; ; ; ; ; ; ; ; ; ;
Doc_ID_19 PO • PO & mainly ST
(Bug tickets) SM ; ; ; ; • Appropriate
ST ; ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_20 PO • PO & mainly ST
(Test Plans) SM ; ; ; ; • Excessive
ST ; ; ; ; ;
Doc_ID_21 PO • PO & mainly ST
(Bug verif. SM ; ; ; ; ; ; ; • Appropriate
report) ST ; ; ; ; ; ; ; ; ; ; ;
Doc_ID_22 PO ; ; ; ; • All roles
(User manual) SM ; ; ; ; • Excessive
ST ; ; ; Table 7.
Doc_ID_23 PO • PO & ST Relevance of the 23
(Quality SM ; ; ; ; ; • Excessive documents for the three
procedures) ST ; ; ; ; ;
Scrum roles
TQM Project Initiation Stage
Doc_ID_01 (Product Backlog), Doc_ID_02 (International Specifications),
Doc_ID_03 (Standards and Regulations) and Doc_ID_04 (Stakeholder
Requirements) and Doc_ID_23 (Quality Procedures)

Sprint

Start of the Sprint

Doc_ID_01 (Product Backlog),
Doc_ID_02 (International
Specifications), Doc_ID_03 Within the Sprint End of the Sprint
Doc_ID_17 (Unit tests), Doc_ID_18 Doc_ID_09 (Demo
(Standards and Regulations),
(Source Code), Doc_ID_19 (Bug Recordings), Doc_ID_10
Doc_ID_04 (Stakeholder
Tickets), Doc_ID_08 (Test (Retro notes), Doc_ID_17
Requirements), Doc_ID_05
verification report), Doc_ID_15 (Unit Tests), Doc_ID_21
(Business Flows), Doc_ID_06
(Developer documentation) and (Bug verification notes) and
(Road Map), Doc_ID_07
Doc_ID_22 (User Manual) Doc_ID_12 (Risk analysis
(Features), Doc_ID_13/14 (Tech
& DB Design), Doc_ID_20 (Test reports)
Plans) and Doc_ID_23 (Quality
Procedures)

Over the Sprint

Doc_ID_11 (Training materials), Doc-ID-12 (Risk Analysis Reports), Doc_ID_16 (Traceability matrices) and
Doc_ID_19 (Bug Tickets)
Figure 1.
Documentation used at
Project Release Stage
various stages in the Doc_ID_11 (Training materials), Doc_ID_16 (Traceability matrices) and
Scrum project Doc_ID_12 (Risk analysis reports)

Participants noted many instances when the “Purpose” section was incomplete or not clearly
stated in documents. This resulted in increased customer queries. Scrum team members
added that incomplete documents made them unaware of the importance these documents
may hold for customers. So, when they saw that end-users had logged clarification support
requests on basic functionalities, they were often clueless as the mentioned functionalities
seemed rather obvious to them. However, later on going over the logged requests, they
realized that either the documentation was incomplete or not explicit. For example, while the
term “backend” meant database to software teams, this meaning was not made explicit in the
end-user manual. Documentation meant for the end-users often contained lingo commonly
used by the software teams. Another concern voiced was the lack of skilled document writers
which affected QA practices in Scrum projects.
Participants further stated that their workload increased when requirement changes were
to be made. Existing documents (listed in Table 3) had to be re-visited and corrected, which
was rather demanding and time-consuming. The developers would often be handling some
other projects that had tight deadlines; therefore, having to complete documentation of a
previous project increased work-related pressures. Other concerns raised were incomplete
and inaccurate descriptions, which caused work disruptions until proper clarifications could
be obtained. This in turn led to some irritation among team members. Also, there were no
common standards over documentation that was being maintained by different Scrum teams.
Most of the professionals considered some documents to be unnecessary. They added that
the reason these documents were made was to comply with administrative requirements
rather than for checking or for validity reasons. Some further added that they would often
leave documentation tasks to the last minute, which resulted in incomplete and hasty work
that was not as explicit as it should be. Both POs and SMs said that a common
misunderstanding among the STs was that agile methods should be devoid of
documentation, and hence they put less effort in document writing. Table 8 provides the Documentation
participant perspectives in their voices. requirements
for ISO 9001
8. Case analysis
This section synthesizes the empirical data produced from the three investigative rounds to
provide a richer perspective on QMS practice in the selected organization (Health-IT).
Responses from software professionals have been analysed to understand how “light-
weight” Agile/Scrum approaches are applied with the formal practices associated with ISO
9001 documentation. Next, we have consolidated participant views on what documents are
produced, when are they produced or are updated, who refers to these documents, how much
content is considered appropriate by them and whether they face any issues in maintaining
the documentation.
Auditors for QMS insist on documentary evidence to verify how quality obligations have
been met over PDCA cycles. All professionals are required to follow the global regulation
specifications set for software industry (Doc_ID_02 and Doc_ID_03) and the company’s
quality procedures (Doc_ID_23) at all stages of development. Planning stage comprises
maintenance of an ordered list (or backlog) of requirements (Doc_ID_01), user requirements
(Doc_ID_04), setting up the start-to-end business processes (Doc_ID_05) and defining long-
and short-term goals (Doc_ID-06). Further, traceability matrices to ensure all customer
requirements are covered (Doc_ID_16) and handling of unforeseen risks (Doc_ID_12) are
detailed. These documents help professionals plan strategies for managing intermediate
deliverables and make timely product releases.
In the development stage, the planning documents are referenced, as professionals utilize
Scrum strategies to build various software components. Documents pertaining to features
required (Doc_ID_07), technical and database designs (Doc_ID_13 and Doc_ID_14), test
plans (Doc_ID_20), source code files (Doc_ID_18) and other developer documentation records
(Doc_ID_15) are created. Checking of intermediate deliverables are done as soon as possible,
so that defects are found early, and the consequences of bugs are minimal. Therefore, reports
quantifying results and benefits to all concerned from unit tests which were conducted
(Doc_ID_17) or issue of bug tickets (Doc_ID_19), and other related verification descriptions
(Doc_ID_08 and Doc_ID_21) are created. Teams make demo recordings of their deliverables
(Doc_ID_09) and retrospective notes (Doc_ID_11) for referencing in the next sprints.
Professionals act on these reports (e.g. Doc_ID_08, Doc_ID_17, Doc_ID_19 and Doc_ID_21)
to enhance the value of the deliverable and bring about learning and process improvements.
A variety of training materials (Doc_ID_11) are provided to internal staff over their product
development journey so that they can learn about new products or new practices. Finally,
development teams create user manuals (Doc_ID_22) that detail utilities offered by the
product to be released to the end-users.
Professionals also categorized various job positions with the usually allocated Scrum roles
(i.e. PO, SM and ST). Product owners are persons holding high authority and mainly hold an
admin role. They are interested in paperwork regarding supervision or if we can daresay in
“policing” workflows. The PO do not deal with operational tasks rather they review the
general section of the documents: who created or signed off the document, purpose of the
document and overall workflow (via flow-charts or diagrams). Scrum master is the champion
who is accountable for project’s execution and leads the team. The SM decides on project
execution, time allocated for project schedules, priorities within a Sprint and whether the
review process objectives are being met properly. The SM ensure both “policing” and
“creativity” goes hand-in-hand when they interact with the Scrum team. Therefore, the SM is
interested in “verification” and “validation” sections as these sections warrant that releases
have been checked for identified defects and all supporting documents are up-to-date.
TQM Respondents views regarding technical nature of the documentation

PO (1) The documents which are presented to customers such as user manuals and admin manuals are
often written from a developer’s perspective. This makes it harder for the non-technical customers
to understand and interpret the instructions. As a result of this, customer support engineers get
very busy in explaining the contents in the documents
(2) When analysing the bugs raised by the customers, it becomes clear that the bugs could have been
easily prevented, if the development team has provided correct and comprehensive documents
SM (1) The “release notes” are often not written in a way that is useful or meaningful to the client. These
documents do not really explain how an issue might affect the client or how the issue could be fixed
(2) If we fix a bug, we state that the identified bugs are fixed for the release. But we haven’t bothered to
mention the information in the release notes. Missing information is often related to questions such
as: (1) What is the bug? (2) Why is it fixed? (3) Where was it fixed? (4) Which part of the functionality
is affected? and (5) Who are the potential customers who need an upgrade?
ST (1) Those who have a passion to write documents do not know the technical implementation details,
and those people who know such details do not like or do not know how to write documents in a
readable manner
(2) Often, people are not interested in articulating how a problem was solved. For the most part, non-
technical people do not see the bigger picture; therefore, it becomes harder to explain the real
content
Respondents views regarding incomplete or inaccurate documentation
PO (1) For internal documents, not having stated the purpose of the document makes it harder to capture
why the document has been created
SM (1) Due to the existence of cross-functional teams, most teams do not have a dedicated technical writer
to prepare documents tailored to the client
(2) There have been many instances when teams had to work without skilled and qualified document
writers; this hinders the production of useful and valuable documents
ST (1) Not having a dedicated person to write documents often leads to having no or few (less than
optimal) documents being produced; this is due to all resource personnel of the project being busy
on their assigned tasks. No one has enough time to maintain proper documentation
(2) If we do a proper analysis and follow up with customer feedback, we could have offered them better
documents than we are offering them now
Respondents views regarding extra workload resulting from documentation
PO (1) Due to poorly understood documented requirements and business cases, the development teams
have to re-work on the code and the test cases after the customer seeks certain clarifications of the
product
SM (1) Stakeholder requirements need to be clearly specified and signed-off. When this does not happen,
the product requirement is considered to have not been validated by the stakeholder before the
commencement of development
(2) Sometimes the deadline/resources or the budget can become a hurdle to adhere to the
documentation standards
ST (1) Excessive rework is an issue. When doing development, it is hard to make sure who defined the
requirements in some cases as the author/purposes is not defined at the right time; this is specially
the case when requirements are defined earlier by a different team and given to another team for
development
(2) Due to strict deadlines and shortage of time, people cut down the focus on documents; this results in
problems later on. Also, it becomes even harder to do it later as it is more time consuming
Respondents views regarding lack of standards in the documentation
Table 8. PO (1) Not specifying the purpose of a document is a common case. This makes it harder for the
Respondents views development teams to define, keep track of the version the document and its validity at a particular
regarding point in time
documentation
challenges (continued )
Respondents views regarding technical nature of the documentation
Documentation
requirements
SM (1) Not having authorship and internal communications committed within the team has resulted in for ISO 9001
misguided vision and motivation for the team to deliver work
(2) Having a companywide strategy to write documents will make it easier for teams to refer to
documents
ST (1) Quite a number of documents being produced by one team becomes ambiguous to another team;
there is little common language/framework being used
(2) Having no maintained product backlog means that the team starting on a certain body of work have
to abandon the work mid-cycle to work on another body of work. This causes disruption in the flow
and upsets the team morale
(3) Having no properly defined sprint backlog increases the amount of re-design, development and
testing of the product. This will affect negatively on the teams’ velocity towards succeeding sprints
Respondents views regarding setting of documentation priorities in Scrum projects
PO (1) Documentation is not considered a deliverable to some stakeholders unfortunately; hence, it
becomes difficult to justify time and effort spent on these activities
(2) Cultivating passion and motivation to create documents is the hardest challenge. It is commonly
labelled as tedious and uninteresting, yet it has a significant place in delivery. Most teams find it
tedious to document what they have done or considered during development
(3) Leaving till the last minute to create the documents results in rushed work. This often leads to
omission of important information, which could have been captured parallel to development
SM (1) The feature document is something that is left to the last minute and time constraints mean that it
ends up being brief (or not being very useful); this means rework, as the document needs to be
re-written late
(2) There is a common misconception among some Scrum practitioners that Agile means no
documentation!
(3) When people think that agile projects should not involve documentation, it becomes hard to
convince them to write proper and useful documents
ST (1) Having too many documents in an organization always require proper reasons being provided to
validate the existence of a document
(2) Due to strict deadlines/timelines and shortage of time, people cut down the focus on documents; this
results in problems later on. Also, it becomes even harder to do it later as it is more time consuming
(3) Not having the right people around at the right time makes production of documents harder. Often,
the product owner is not at hand to provide sufficient details and/or the architects are not available
to guide the team in the right direction
(4) Some tools are either not fit for the purpose of documentation or the development team has yet to
optimize or automate Table 8.

SMs have to operate in an atmosphere of trust to gain confidence of the team and the
management. Finally, Scrum teams are the creators who use their technical expertise to
execute the project; hence, they are more interested in the technical and operational contents.
STs are more interested in functional material like “development instructions” and
“verification and validation” of the associated documents. Over the sprint duration, the
teams create, update and refer to quite a few documents as they deal with complex and
interdependent project tasks. While teams realize the QA value of some documents, they
consider much of the other documentation excessive and prefer “light-weight” approaches for
tackling epics or user stories.
Documentation issues too have been highlighted across the three Scrum roles. These
include: (1) technical nature of documentation which is not easily understood by non-technical
end-users or customers (2) lack of clarity in expressing the purpose and other incomplete
documentation, (3) increase in amount of re-work to incorporate user requested changes to
existing documents, (4) missing validity dates in documents which leads to confusion
regarding their currency and usefulness, (5) lack of risk analysis and backlog reporting that
TQM causes further disruption in subsequent tasks, (6) lack of skilled document writers, (7) the
view among professionals that documentation is not important and is therefore hastily
written at the last minute, (8) lack of common standards in writing documents, (9)
misalignment of documentation tools with developer tasks and (10) increased workload due
to superfluous document maintenance.

9. Discussion, conclusions and future research directions

We have conducted an in-depth empirical enquiry into a specific and complex phenomenon
(i.e. documentation practices) within its real-world context (i.e. ISO compliance) from varied
perspectives (i.e. Scrum roles) (Yin, 2013). Halkier (2011, p. 789) define practices as “dynamic
multirelational configurations” comprising interactions and negotiations; they warn
researchers to consider the underlying situational and dynamic positions when
generalizing knowledge categories from empirically drawn practices. This enquiry has
identified knowledge categories for QMS documentation practices that are specific to a single
case context; hence, its generalizability is context bound to the interpretations of the standard
and the practices of the company’s auditor, software professionals and management. The
“positioning” of ISO 9001 documentation practices at different stages in Scrum projects has
assisted in providing better perspective and for drawing inferences. Positioning as a form of
analytical generalization enables researchers to infer from the communicative dynamisms
represented by “group interactions, negotiations, conversational processes and discourses”
that take place as part of the practice (p. 793). The exchanges that took place among software
professionals when using “light-weight” agile/Scrum methods with ISO 9001 has helped
make analytical generalizations regarding operative documentation practices.
In light of the research question – What level of documentation should be adopted in Scrum
projects for maintaining ISO 9001 compliance? – we have identified two key points from our
case study. One, the “light-weight” nature of Scrum methodologies comprising series of
iterative and incremental practices (or sprints) can conflict with clause-based “heavy-weight”
approaches of ISO 9001. Our empirical investigation found that of the list of 23 documents
used for ISO 9001 compliance by our selected case organization, only 13 documents were
considered somewhat useful across the three Scrum roles. Hence, too many documents for
compliance reasons can cause tension among professionals towards documentation upkeep.
Second, we found that it is not the high-level documentation (e.g. quality policy, quality
manual) that causes tensions with agile/Scrum projects rather tensions are in maintaining
certain operational-level documents. Our investigation has revealed maintenance issues, such
as incomplete, hidden (abstract) and inconsistent requirements, missing traceability, moving
targets, terminology problems and management’s assumptions that developers are aware of
customer’s business. Some of these issues have been highlighted in previous studies for agile
and plan-driven processes (e.g. Lemos et al., 2012; Fernandez et al., 2017). Moreover,
preserving innovative capabilities are difficult when implementing ISO 9001 documentation
since these formally laid out documents require continuous monitoring that can cause
tensions (Klute-Wenig and Refflinghaus, 2020). We therefore propose that software
organizations pursuing Agile/scrum projects alongside ISO 9001 compliance should
review their current level of documentation with concerned software professionals. This
will enable better integration of ISO 9001 documentation with the flexible and fast-changing
nature of agile developmental approaches.
In regard to the second research question – How are current ISO 9001 documentation
requirements for Scrum projects perceived by software professionals? – our findings shed light
on tensions faced in maintaining proper documentation. We find that the QA documents are
perceived differently across the Scrum roles; hence in having one uniform template with
many sections and sub-sections for all document types is deemed unnecessary and excessive.
Findings suggest that the product owner is mainly concerned with management reporting Documentation
documents, while the Scrum master is engaged in a mix of management reporting and requirements
operational documents. The Scrum teams considers documentation to be low priority, and
their interest lies with operational documents pertaining to the technical domains of their
for ISO 9001
work. Our case in particular has shown that little attention is given to documentation practice
by Scrum teams, who put less effort into completing the documentation. This leads to missing
content (e.g. unclearly stated purpose, missing validity date, etc.) and delays in updates to the
end-user documents. Incorrect or incomplete documentation in turn creates a project risk and
increases rework that affects product quality. The extant literature too has highlighted the
importance of effective documentation for end-users (customers) and suggests that user
manuals act as secondary products that add value to the primary product (G€ok et al., 2019).
User manuals can reduce inadvertent errors often caused by customers, increase users’
quality perceptions of the product and enhance the firm’s reputation. Our observation too is
that when faced with a lack of skilled technical writers, firms may entrust customer-related
documentation tasks to their technical staff (or Scrum teams). This causes further tension
among the team members who consider much of the documentation tasks to be superfluous.
Chiarini et al. (2019) are of the view that QMS documentation (e.g. ISO 9001) can introduce
“red tape” and bureaucracy that can result in “higher time consumption and additional daily
work for employees, as well as for top management” (Klute-Wenig and Refflinghaus, 2020,
p. 440). Further, certain concepts are ambiguously stated in the text of ISO standards, which
can at the very least complicate or distort its implementation and impact the auditing process
(Anttila and Jussila, 2017). Therefore, auditors inspecting ISO 9001 compliance should ensure
that processes are operating under controlled conditions rather than follow the conventional
quality audit process that is clause-based (Domingues et al., 2019). The practice of checking
actions taken for each clause (and even subclauses) can cause tensions in the QMS
implementation. Our empirical exploration reveals many aspects of the tension faced by
professionals in meeting QMS documentation requirements with “light-weight” Scrum
methods in our chosen case organization. Scrum emphasizes face-to-face communication
within an environment of trust; it does not rely solely on in-process documents since issues
are mostly resolved during the sprint retrospectives (Hanssen et al., 2018). Our study further
affirms that Scrum professionals consider much of the ISO 9001 documentation tasks to be
cumbersome requiring extraneous effort. While some documentation is necessary, the
auditors focus should be on addressing operational risks and plans on preventing them in the
given business context (Klute-Wenig and Refflinghaus, 2020). That is, documentation for
agile/Scrum projects should be linked to core processes that focus on preserving innovative
capabilities and improving performance in the long-term rather than rigidly reviewing some
documented control procedure. This will help overcome tensions associated with order (or
control) needed for ISO 9001 compliance and the “structured freedom” that comes with Scrum
methods.
However, like most disciplines, quality management and operations management
approaches such as agile are maturing. There is a great deal of interplay between quality
management systems (e.g. ISO 9001) and operations management (e.g. Scrum), with each
discipline being cross-fertilized by the other. The recent ISO/IEC/IEEE 26515:2018 standard
recognizes the evolving nature of software requirements in agile environments (ISO/IEC/
IEEE_International_Standard, 2018). Lessons learned from agile development have assisted
in defining documentation expectations when dealing with software products being built
with “light-weight” approaches in the new standard version. That is, while agile does not
mean zero documentation, too much source documentation can reduce flexibility and
effectiveness. Our case study too affirms that although internal and external stakeholders
expect some level of documentation for Scrum projects, too much attention on document
standardization can make software professionals feel over-policed and micro-managed.
TQM Xie et al. (2016) advise standardization involving knowledge codification for modular
innovation and problem-solving capabilities. The new ISO/IEC/IEEE 26515:2018 standard
has clauses specific for agile development. The clause 5 (Information development process)
concedes that software requirements will change and therefore “discourages the creation of
detailed engineering support documentation and detailed technical specifications” (p. 4). The
clause 6 (Management of information development) refrains from “the use of detailed lifecycle
documentation” for local teams although remote teams may rely on formally written
communication (p. 5). And the clause 7 (Preparing information for users) recommends
document updates that “allow for rapid changes to the content and for reverting content
updates to reflect changes and reversions in the product or service” (p. 19). This means that
many of the documents that have been mapped to various stages of Scrum projects (shown in
Figure 1) may need to be consolidated for their content and viability if the ISO/IEC/IEEE
26515:2018 standard is to be implemented.
Finally, although agile approaches are widely used, the number of studies on challenges
related to co-existence of autonomous agile methods with plan-driven development is scarce
(van Waardenburg and van Vliet, 2013; Tarhan and Yilmaz, 2014). Our investigation has
provided an empirical view on these challenges. While our findings are limited to one case, we
have ensured plurality of reasoning by considering views of multiple Scrum practitioners to
understand aspects of ongoing tensions that come with QMS documentation. Larsson (2009)
adds that plurality increases variation in the sample range that enhances its generalization
potential. Our findings can provide a background to future research studies that consider
agile methods in different types of organisations to identify documentation issues specific to
that organisation and to their product type.

Note
1. pseudonym.

References
Anttila, J. and Jussila, K. (2017), “ISO 9001:2015 – a questionable reform. What should the
implementing organisations understand and do?”, Total Quality Management and Business
Excellence, Vol. 28 Nos 9-10, pp. 1090-1105, doi: 10.1080/14783363.2017.1309119.
Boddy, C.R. (2016), “Sample size for qualitative research”, Qualitative Market Research: An
International Journal, Vol. 19 No. 4, pp. 426-432, doi: 10.1108/QMR-06-2016-0053.
Cellucci, L.W., Trimmer, K., Farnsworth, T. and Waldron, A. (2011), “The implementation of a health-
IT academic focus: a case study”, 2011 44th Hawaii International Conference on System
Sciences, Kauai, HI, USA, 4-7 Jan. 2011, IEEE.
Chen, Y. (2013), “Towards collaborative-oriented health IT systems design”, 2013 International
Conference on Collaboration Technologies and Systems (CTS), San Diego, CA, USA, 20-24 May
2013, IEEE, pp. 479-480.
Chiarini, A., Castellani, P. and Rossato, C. (2019), “Factors for improving performance in ISO 9001
certified small- and medium-sized service enterprises”, The TQM Journal, Vol. 32 No. 1,
pp. 21-37, doi: 10.1108/TQM-05-2019-0141.
Daneva, M., van der Veen, E., Amrit, C., Ghaisas, S., Sikkel, K., Kumar, R., Ajmeri, N., Ramteerthkar,
U. and Wieringa, R. (2013), “Agile requirements prioritization in large-scale outsourced
system projects: an empirical study”, Journal of Systems and Software, Vol. 86 No. 5,
pp. 1333-1353, doi: 10.1016/j.jss.2012.12.046.
de Vries, H., J. and Haverkamp, A. (2015), “Overcoming resistance against quality control – a
philosophical-empirical approach”, International Journal of Quality and Reliability Management,
Vol. 32 No. 1, pp. 18-41, doi: 10.1108/IJQRM-01-2013-0004.
Dikert, K., Paasivaara, M. and Lassenius, C. (2016), “Challenges and success factors for large-scale Documentation
agile transformations: a systematic literature review”, Journal of Systems and Software,
Vol. 119, pp. 87-108, doi: 10.1016/j.jss.2016.06.013. requirements

Domingues, P., Reis, A.M., Fonseca, L.M., Avila, P. and Putnik, G.D. (2019), “The added value of the
for ISO 9001
ISO 9001:2015 international standard from an auditors’ perspective: a CB-SEM based
evaluation”, International Journal for Quality Research, Vol. 13 No. 4, pp. 967-986, doi: 10.
24874/IJQR13.04-15.
Everett, G.D. and McLeod, R.J. (2007), Software Testing: Testing across the Entire Software
Development Life Cycle, John Wiley & Sons, Hoboken, New Jersey.
Fernandez, D.M., Wagner, S., Kalinowski, M., Felderer, M., Mafra, P., Vetro, A., Conte, T., Christiansson,
M.T., Greer, D., Lassenius, C., M€annist€o, T., Nayabi, M., Oivo, M., Penzenstadler, B., Pfahl, D.,
Prikladnicki, R., Ruhe, G., Schekelmann, A., Sen, S., Spinola, R., Tuzcu, A., de la Vara, J.L. and
Wieringa, R. (2017), “Naming the pain in requirements engineering”, Empirical Software
Engineering, Vol. 22 No. 5, pp. 2298-2338, doi: 10.1007/s10664-016-9451-7.
uhan, G. (2019), “The effect of user manual quality on customer satisfaction:
G€ok, O., Ersoy, P. and B€or€
the mediating effect of perceived product quality”, The Journal of Product and Brand
Management, Vol. 28 No. 4, pp. 475-488, doi: 10.1108/JPBM-10-2018-2054.
Halkier, B. (2011), “Methodological practicalities in analytical generalization”, Qualitative Inquiry,
Vol. 17 No. 9, pp. 787-797, doi: 10.1177/1077800411423194.
alhane, T. and Myklebust, T. (2018), “Documentation and proof-of-compliance”, in
Hanssen, G.K., St

Hanssen, G.K., St
alhane, T. and Myklebust, T. (Eds), SafeScrum® – Agile Development of
Safety-Critical Software, Springer International Publishing, Cham. doi: 10.1007/978-3-319-99334-
8_9.
Hooper, J.H. (2001), “The process approach to QMS in ISO 9001 and ISO 9004”, Quality Progress,
Vol. 34 No. 12, pp. 70-73.
Hussain, T., Eskildsen, J.K. and Edgeman, R. (2020), “The intellectual structure of research in ISO 9000
standard series (1987–2015): a Bibliometric analysis”, Total Quality Management and Business
Excellence, Vol. 31 Nos 11-12, pp. 1195-1224, doi: 10.1080/14783363.2018.1469977.
[ISO] International_Organization_for_Standardization (2016), “AS/NZS ISO 9001:2000 Quality
management systems-Requirements”, Quality Management Systems: Joint Technical
Committee QR-008. 44, Standards Australia International, Sydney, available at: https://www.
standards.govt.nz/search-and-buy-standards/standards-information/quality-management-
systems/.
[ISO] International_Organization_for_Standardization (2019), “Guidance on the requirements for
documented information of ISO 9001:2015”, ISO/TC 176/SC2/N1286, International Organization
for Standardization, Geneva, Switzerland, available at: https://www.iso.org/files/live/sites/
isoorg/files/archive/pdf/en/documented_information.pdf.
[ISO/IEC/IEEE] ISO/IEC/IEEE_International_Standard (2018), “Systems and software engineering –
developing information for users in an agile environment”, ISO/IEC/IEEE 26515:2018,
International Standards Organization and International Electrotechnical Commission,
Geneva, Switzerland, pp. 1-22, available at: https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:
26515:ed-2:v1:en.
Klute-Wenig, S. and Refflinghaus, R. (2020), “Quality management for microenterprises and start-ups –
is the ISO 9001 suitable?”, International Journal of Quality and Service Sciences, Vol. 12 No. 4,
pp. 435-446, doi: 10.1108/IJQSS-01-2018-0003.
Larman, C. and Basili, V.R. (2003), “Iterative and incremental developments. a brief history”,
Computers in Industry, Vol. 36 No. 6, pp. 47-56, doi: 10.1109/MC.2003.1204375.
Larsson, S. (2009), “A pluralist view of generalization in qualitative research”, International Journal of
Research and Method in Education, Vol. 32 No. 1, pp. 25-38, doi: 10.1080/17437270902759931.
TQM Lemos, J., Alves, C., Duboc, L. and Rodrigues, G.N. (2012), “A systematic mapping study on creativity
in requirements engineering”, Proceedings of the 27th Annual ACM Symposium on Applied
Computing, Trento, Italy, ACM.
Leung, H.K., Liao, L. and Qu, Y. (2007), “Automated support of software quality improvement”,
International Journal of Quality and Reliability Management, Vol. 24 No. 3, pp. 230-243, doi: 10.
1108/02656710710730843.
Manders, B. (2014), “Implementation and impact of ISO 9001 (No. EPS-2014-337-LIS)”, in ERIM (Ed.),
Series Research in Management, Rotterdam Erasmus Research Institute of Management.
Mathrani, A. and Mathrani, S. (2013), “Test strategies in distributed software development
environments”, Computers in Industry, Vol. 64 No. 1, pp. 1-9, doi: 10.1016/j.compind.2012.
09.002.
Mathrani, A. and Parsons, D. (2012), “Managing meta-learning in offshore software development
environments”, Journal of Management Development, Vol. 31 No. 6, pp. 565-583, doi: 10.1108/
02621711211230867.
McMichael, B. and Lombardi, M. (2007), “ISO 9001 and agile development”, Proceedings of the AGILE
2007, IEEE Computer Society.
Mishra, D. and Abdalhamid, S. (2018), “Software quality issues in scrum: a systematic mapping”,
Journal of Universal Computer Science, Vol. 24 No. 12, pp. 1690-1716, doi: 10.3217/jucs-024-
12-1690.
Murmura, F. and Bravi, L. (2017), “Empirical evidence about ISO 9001 and ISO 9004 in Italian
companies”, The TQM Journal, Vol. 29 No. 5, pp. 650-665, doi: 10.1108/TQM-11-2016-0097.
Murray, W. (2016), “Risk and ISO 9001: 2015”, Quality, available at: https://www.qualitymag.com/
articles/93103-risk-and-iso-9001-2015.
Myhrberg, E.V. (2009), A Practical Field Guide for ISO 9001:2008, ASQ Quality Press, Nashwille, M.
Poksinska, B., Dahlgaard, J., J. and Eklund, J.A.E. (2006), “From compliance to value-added auditing –
experiences from Swedish ISO 9001:2000 certified organisations AU - poksinska, Bozena”, Total
Quality Management and Business Excellence, Vol. 17 No. 7, pp. 879-892, doi: 10.1080/
14783360600595294.
Qasaimeh, M. and Abran, A. (2013), “An audit model for ISO 9001 traceability requirements in agile-
XP environments”, Journal of Software, Vol. 8, pp. 1556-1567, doi: 10.4304/jsw.8.7.1556-1567.
R€
ueping, A. (2003), Agile Documentation: A Pattern Guide to Producing Lightweight Documents for
Software Projects, John Wiley & Sons, Chichester, West Sussex PO19 8SQ, England.
Runeson, P., Host, M., Rainer, A. and Regnell, B. (2012), Case Study Research in Software Engineering,
John Wiley and Sons, Hoboken, NJ.
Saier, M.C. (2017), “Going back to the roots of W.A. Shewhart (and further) and introduction of a new
CPD cycle”, International Journal of Managing Projects in Business, Vol. 10 No. 1, pp. 143-166,
doi: 10.1108/IJMPB-11-2015-0111.
Santos, G., Rebelo, M., Lopes, N., Alves, M.R. and Silva, R. (2016), “Implementing and certifying ISO
14001 in Portugal: motives, difficulties and benefits after ISO 9001 certification”, Total Quality
Management and Business Excellence, Vol. 27 Nos 11-12, pp. 1211-1223, doi: 10.1080/14783363.
2015.1065176.
Schwaber, K. and Sutherland, J. (2013), “The Scrum guide: the definitive guide to Scrum: the rules of
the game”, [Online], available at: https://www.verheulconsultants.nl/Scrum%20Update%
202013.pdf (accessed).
Schwalbe, K. (2019), Information Technology Project Management, Cengage Learning, Boston.
Sfreddo, L.S., Vieira, G.B.B., Vidor, G. and Santos, C.H.S. (2021), “ISO 9001 based quality management
systems and organisational performance: a systematic literature review”, Total Quality
Management and Business Excellence, Vol. 32 Nos 3-4, pp. 389-409, doi: 10.1080/14783363.2018.
1549939.
Sligo, J., Gauld, R., Roberts, V. and Villa, L. (2017), “A literature review for large-scale health Documentation
information system project planning, implementation and evaluation”, International Journal of
Medical Informatics, Vol. 97, pp. 86-97, doi: 10.1016/j.ijmedinf.2016.09.007. requirements
alhane, T. and Hanssen, G.K. (2008), “The application of ISO 9001 to agile software development”, in
St

for ISO 9001
Jedlitschka, A. and Salo, O. (Eds), Product-Focused Software Process Improvement - PROFES
2008, Springer, Berlin, Heidelberg. doi: 10.1007/978-3-540-69566-0_30.
Stoica, M., Mircea, M. and Ghilic-Micu, B. (2013), “Software development: agile vs. Traditional”,
Informatica Economica, Vol. 17 No. 4, pp. 64-76, doi: 10.12948/issn14531305/17.4.2013.06.
Summers, D.C.S (2018), Quality, Pearsons, Boston.
Tarhan, A. and Yilmaz, S.G. (2014), “Systematic analyses and comparison of development
performance and product quality of Incremental Process and Agile Process”, Information
and Software Technology, Vol. 56 No. 5, pp. 477-494, doi: 10.1016/j.infsof.2013.12.002.
Tomic, B. and Brkic, V.K.S. (2019), “Customer satisfaction and ISO 9001 improvement requirements in
the supply chain”, The TQM Journal, Vol. 31 No. 2, pp. 222-238, doi: 10.1108/TQM-07-2017-0072.
van Waardenburg, G. and van Vliet, H. (2013), “When agile meets the enterprise”, Information and
Software Technology, Vol. 55 No. 12, pp. 2154-2171, doi: 10.1016/j.infsof.2013.07.012.
Wealleans, D. (2017), The Quality Audit for ISO 9001: 2000: A Practical Guide, Gower Publishing,
London. doi: 10.4324/9781315237534.
Xie, Z., Hall, J., McCarthy, I.P., Skitmore, M. and Shen, L. (2016), “Standardization efforts: the
relationship between knowledge dimensions, search processes and innovation outcomes”,
Technovation, Vols 48-49, pp. 69-78, doi: 10.1016/j.technovation.2015.12.002.
Yin, R.K. (2013), “Validity and generalization in future case study evaluations”, Evaluation, Vol. 19
No. 3, pp. 321-332, doi: 10.1177/1356389013497081.
glu, V., Sun, B., Garousi, G., Shahnewaz, S. and Ruhe, G. (2015), “Cost, benefits
Zhi, J., Garousi-Yusifo
and quality of software development documentation: a systematic mapping”, Journal of
Systems and Software, Vol. 99, pp. 175-198, doi: 10.1016/j.jss.2014.09.042.

Corresponding author
Anuradha Mathrani can be contacted at: a.s.mathrani@massey.ac.nz

For instructions on how to order reprints of this article, please visit our website:
www.emeraldgrouppublishing.com/licensing/reprints.htm
Or contact us for further details: permissions@emeraldinsight.com