The Agile Hazard Log approach

T. Myklebust, R. Bains and G. K. Hanssen

SINTEF ICT, Trondheim Norway
T. Stålhane
NTNU IDI, Trondheim Norway

ABSTRACT: During the last years, there has been an increase in the use of agile development methods when
developing safety-critical systems. This is done to shorten time to market, reduce costs and improve quality.
The hazard log lists and tracks all hazards, hazard analysis results, risk assessment and risk reduction activi-
ties during the whole life of a safety related system. A complete hazard log is normally one of the top five
references in a safety case. The agile hazard log approach enables the manufacturer to have a single source for
risk management activities, simplifies reuse and transfer of information between projects.

1 INTRODUCTION adapted to frequent changes may easily become out-

During the last years, there has been an increase in
the use of agile methods and practices when devel-
oping safety-critical software in order to reduce time
to market, reduce costs and to improve quality.
Companies introducing agile methods like
SafeScrum should also use an Agile Hazard Log
(AHL) to get the full benefit of an agile approach
and at the same time satisfy relevant safety standards
like e.g. EN 5012X series and IEC 61508 series.
The main reason for introducing the AHL is that:
 it is one of the main references in the safety
case. A safety case is required by e.g. EN
50129 (railway) and ISO 26262 (automotive)
 the AHL process is an improved process for
the development and maintenance of the HL,
especially regarding the stronger emphasis
on software development
 when introducing SafeScrum, other parts of
the product development process, the hazard
log being one of those parts, has to be in-
cluded to ensure that all the main parts of the
development process are agile
 the AHL is suited for frequent changes
 the AHL may facilitate a single source ap-
proach for risk management activities
 it simplify reuse and transfer of information
between stakeholders
 and all these agile adaptions shall be per-
formed without compromising the require-
ments given in EN 50128 and IEC 61508
The introduction of the AHL contributes to avoid
SW design errors. Current standards are weak and
do not match the current and future heavily focus on
software processes. A hazard log which is not well
dated, in the sense that it no longer represents the
true picture of risks related to the product being de-
veloped. The AHL enables a structured, agile and
flexible approach allowing for more frequent up-
dates and a shorter time to market.
The AHL may include the Safety Related Applica-
tion Conditions (SRAC) list, but often the SRAC is a
separate document. One of the reason that the SRAC
list is a separate document is that it is often closely
related to the contract.
EN 50126-1 has defined Hazard Log as "The docu-
ment in which all safety management activities, haz-
ards identified, decisions made and solutions adopt-
ed are recorded or referenced".
Our suggestion for a definition of an Agile Hazard
log is:
Information on all safety management activities,
hazards identified, decisions made and solutions
adopted are recorded. This should be collected and
registered in an adaptive, flexible and effective way.
The AHL is developed alongside the product devel-
opment - i.e. in activities performed alongside the
sprints. Sprint is a Scrum term used to describe a
development iteration in the Scrum process. The
AHL related work can be time-boxed together with
the Sprints, but is performed alongside the Sprints.
The Sprint review may include the AHL as a topic
when relevant. The development of the AHL should
preferably be planned together with other alongside
activities like the development of the Agile safety
case by Stålhane and Myklebust (2016), analysis and
independent tests.
This paper starts with background information relat-
ed to hazard logs. We then explain both Scrum and
SafeScrum. Further, the requirements for the hazard
log and the AHL are presented. To ensure an effec-
tive project we have included the reuse and template
approach. Finally, we present the Agile hazard log
process and relevant agile practices.
The rest of this paper is organized as follows: a re-
quirement chapter and possibilities related to reuse
of templates.
This paper has not included the following phases
in the current process description: Manufacturing,
installation and commissioning, operation and
maintenance and decommissioning.
2 BACKGROUND
2.1 Introduction to hazards log
There exist several techniques that can be used when
performing hazard identification. We may use his-
torical safety experience and hazard logs, lessons
learned, trouble reports, hazard analyses, and acci-
dent and incident files. When an acceptable edition
of the "Definition of system" exists, the hazard iden-
tification should start. The system definition is an
important document for developing both the Hazard
log and the safety case. The system definition is also
of crucial importance for the production of evidence
to be included in the safety case. With a frequently
changing world, the system, and thus the system’s
definition, has to be changed frequently. One way to
handle this is to change from a waterfall process to
an agile process.
Risk analysis includes the process whereby hazards
are characterized for their likelihood and severity.
The likelihood may be expressed either in terms of
frequency or in terms probability. The risk calcula-
tions may furthermore be performed either quantita-
tively or qualitatively. In relation to quantitative cal-
culations the risk may be calculated as a product
between likelihood and severity, however, other
possible methods of calculations exists.
The AHL and the process described in this paper
forces the manufacturer to be specific about the haz-
ard process, enabling the Certification Body (CB) to
be proactive and to plan its work according to the
applicant’s schedule.
We have started the work to include the AHL into
the SafeScrum process. This is part of our general
work towards including all or most of the safety
lifecycle phases activities into SafeScrum.
EN 50126-1 is one of the few international safety
standards that require a hazard log to be developed
and it is therefore natural to investigate some of the
overall requirements to the HL in this standard in
order to provide parts of the basis for the develop-
ment of the AHL. According to EN 50126-1: 1999,
the HL "shall be updated throughout the life-cycle
whenever a change to identified hazards occurs or a
new hazard is identified". This implies that the HL
may be updated in any of the life-cycle phases.
However, the establishment of the hazard log is to
be performed as part of Phase 3 Risk analysis. This
can be seen from EN 50126-1 by the fact the majori-
ty of the detailed requirements to the HL are con-
tained in the clauses of EN 50126-1 related to Phase
3 Risk analysis. Even though Phase 3 Risk analysis
is the phase where the HL is first established, some
of the foundation and prerequisites for establishing
the hazard log is made during phase 2: System defi-
nitions and application condition by defining the
scope of system hazard analysis and by performing
preliminary hazard identification. In addition to
lifecycle Phase 3 Risk analysis (the phase when HL
is established), the HL is specifically mentioned
with respect to updates or reviews as part of lifecy-
cle Phase 10: System acceptance, Phase 11: Opera-
tion and maintenance, Phase 13: Modification and
retrofit and Phase 14: Decommissioning and dis-
posal.
The European railway regulation for "the com-
mon safety method for risk evaluation and assess-
ment" (402/2013) hereafter denoted CSM, requires a
hazard log (hazard record). Whereas EN 50126-1
presents requirements to the HL on a rather detailed
level, CSM presents the requirements on an overall,
generic level. The reason for this may be that CSM
define three approaches (application of codes of
practice, comparison with similar systems or explicit
risk estimation) for risk acceptance that may put dif-
ferent constraints on the HL. Important aspects to
highlight for requirements to the HL, is that CSM
requires that the HL is created or updated by the
Proposer of the change, e.g. the manufacture or the
infrastructure manager, during design and imple-
mentation until acceptance of the change or delivery
of the safety assessment report. Once the system has
been accepted and is in operation, the HL shall be
maintained by the infrastructure manager or the
railway undertaking in charge of operation of the
system under assessment. CSM therefore requires
that the responsibility is transferred between the
Proposer (responsible for the design/change) and the
actors responsible for the operation of the system.
Other aspects to highlight related to the HL is that
CSM presents concrete requirements to the system
definition, which will determine the scope of the risk
assessment and the HL. This is also the case for EN
50126-1. CSM further emphasizes that the expertise
from a competent team shall be used as part of the
hazard identification. The risk management process
is also, according to CSM, iterative and ends when
compliance with the safety requirements necessary
to accept the risk is demonstrated.
The Agile hazard log satisfies all the require-
ments mentioned in EN 50126-1:1999 chapter
6.3.3.3. The generic standard series IEC 61508 does
not have requirements for a HL but includes as part
of phase 3: requirements for hazard and risk analysis
(see Fig. 2 below). IEC 61508-1 includes three ob-
jectives: "The first objective of the requirements of
this subclause is to determine the hazards, hazard-
ous events and hazardous situations relating to the
EUC (Equipment Under Control) and the EUC con-
trol system (in all modes of operation) for all rea-
sonably foreseeable circumstances, including fault
conditions and reasonably foreseeable misuse.
The second objective of the requirements of this
subclause is to determine the event sequences lead-
ing to the hazardous events.
The third objective of the requirements of this
subclause is to determine the EUC risks associated
with the hazardous events".
These objectives corresponds well with the EN
50126-1 requirements for the HL. The required haz-
ard and risk analyses may, even though not required
by IEC 61508, be included or referenced in a HL.
1 Concept
2 Overall scope definition
3 Hazard and risk analysis
Figure 1. Extract of Figure 2 in IEC 61508-3.
2.2 SafeScrum
The SafeScrum process is based on a collabora-
tion between research and industry, involving lead-
ing Norwegian providers of safety-critical systems
such as e.g. dynamic positioning, and offshore fire
and gas detection systems. An illustration of the
main part of SafeScrum is provided in Fig. 1. All the
main components of the Scrum process are kept:
- Work (software development) is done in short it-
erations called sprints with a fixed length, e.g.
three weeks.
- Scrum uses incremental development. This is an
old idea – much older than agile development. It
is defined in ISO/IEC/IEEE 24765 3.1377 in-
cremental development - a software development
technique in which requirements definition, de-
sign, implementation, and testing occur in an
overlapping, iterative (rather than sequential)
manner, resulting in incremental completion of
the overall software product.
- Each iteration delivers an increment, which is a
part of the system that can be tested or used as a
basis for providing feedback to relevant stake-
holders and to plan further development. Some of
the iteration may only include test results and
similar work and as a result does not deliver a
system increment.
- Work is normally done by a self-managed devel-
opment team, having complimentary competency
and skills to solve the tasks in the project. There
is no project leader in the Sprint team. Instead, a
scrum master has the responsibility of keeping
the process running and dealing with problems
that might arise during development. Each work-
ing day starts with a short meeting where each
member explains their results from the previous
workday, any problems they have encountered,
and their plan for the day.
- The team interacts with a product owner (in a
normal agile setting), which is responsible for de-
fining requirements and providing feedback to
the development team.
- There is no detailed requirement specification up-
front in a normal agile setting but an SRS (safety
requirement specification) is included in the
SafeScrum process. High-level requirements are
kept in a product backlog, which is a list of fea-
tures the system needs to have. Prior to each
sprint, in a sprint-planning meeting, the product
owner prioritizes the features that shall be devel-
oped in the sprint. The team details the tasks, es-
timates time for development, and add the tasks
to the sprint backlog, which is a list of features
that are going to be implemented in the upcoming
sprint.
- The sprint ends with a sprint review meeting
where the team demonstrates the resulting incre-
ment and the product owner provides feedback to
the team.
Figure 2: The SafeScrum process when mainly considering
phase 10 of IEC 61508 and phase 6 of EN 50126
 SafeScrum extends the basic Scrum model in or-
der to make the process applicable for development
and certification of safety-critical software:
- The SRS are included as this is required by the
safety standards. In addition practices like safety
stories Myklebust and Stålhane (2016) and the
backlog are included to ensure that the software
engineers fully understands the requirements.
- The product backlog is split into two parts, one
with functional requirements and one with safety
requirements. Alternatively, the safety require-
ments can be tagged for identification. In addition
we provide information to link functional re-
quirements relevant safety requirements. With
these links we can keep track of how each item in
the functional product backlog relates to the items
in the safety product backlog, i.e. which safety
requirements are affected by which functional re-
quirements? The linking can be done by using
simple cross-references in the two backlogs and
can also be supported by adding an explanation of
how the requirements are related if this is needed
to fully understand a requirement. The linking of
e.g. stories to hazards and corresponding safety
requirements can be part of the AHL work. This
is useful when we want to trace how changes in
functional requirements affect safety require-
ments.
- All development and change of requirements and
code are traced. The trace information is a fun-
damental part of the information that has to be
provided to the assessor in order to prove con-
formance to the standard. Based on experience so
far, we see that clever use of tools together with
tool interoperability are important to automate
production and maintenance of documentation
and traceability.
- We have included an additional role for internal
quality assurance within the SafeScrum process.
This person , who is part of the team, will contin-
uously verify that all quality assurance tasks have
been performed Hanssen et al (2016).
- When a sprint is planned and in cases where exist-
ing code is being changed, the team must do a
change impact analysis Myklebust et al 2014 to
evaluate whether the change will affect the safety
of the system.
- Each sprint ends with a sprint review meeting,
which also encompasses a RAMS evaluation to
ensure that the last increment does not violate the
safety functionality of the system.
A process like SafeScrum may help a develop-
ment organization in addressing some of the prob-
lems that we have identified through the survey
Myklebust et al (2017). Short iterations open for
frequent evaluation of the design and of the safety
function of the system. It also forms a basis for fre-
quent communication, both within the team, with the
product owner (e.g. the customer), and with the as-
sessor. The key principle is to uncover and correct
problems as early as possible in development. This
can be communicated by incremental development
of an Agile Safety Case by Stålhane and Myklebust
(2016).
3 THE AGILE HAZARD LOG AND RELATED
REQUIREMENTS
The Agile HL has to satisfy the relevant safety
standards so the requirements for an Agile HL and
an ordinary HL are more or less the same.
In the EN 5012X series, the main requirements
related to hazard identification and hazard processes
are included in EN 50126-1 and EN 50129, while
the requirements and information in EN 50128 is of
little help except that the validator has to ensure that
the related hazard logs and remaining non-
conformities are reviewed and that all hazards are
closed in an appropriate manner through elimina-
tion or risks control/transfer measures.
Figure 3. Backlog and hazard analysis
Note that the majority of requirements related to
HL in EN 50126-1 and EN 50129 are on the HL it-
self and to a lesser degree specific requirements on
the process (even though EN 50126-1 states when in
which life-cycle phases the HL shall be updated or
reviewed). In the current paper, both the Agile HL
requirements (described in the current chapter) and
the process is described in chapter 5.
According to EN 50126-1:1999 the hazard log
shall include or refer to details of:
a) the aim and purpose of the Hazard Log
b) each hazardous event and contributing com-
ponents.
c) likely consequences and frequencies of the se-
quence of events associated with each hazard.
d) the risk of each hazard.
e) risk tolerability criteria for the application.
 f) the measures taken to reduce risks to a tolera-
ble level, or remove, the risk for each hazardous
event.
g) a process to review risk tolerability.
h) a process to review the effectiveness of risk re-
duction measures.
i) a process for on-going risk and accident re-
porting.
j) a process for management of the Hazard Log.
k) the limits of any analysis carried out.
I) any assumptions made during the analysis.
m) any confidence limits applying to data used
within the analysis.
n) the methods, tool and techniques used.
o) the personnel, and their competencies, in-
volved in the process.
The list presented immediately above represents a
rather detailed list of requirements to the HL. Expe-
rience obtained by two of the authors of this paper
from projects that have followed EN 50126-1 has
shown that:
- In relation to requirement b) in the list above,
often a limited set of top hazards (typically
five to 12 hazards in the railway signalling
domain) are defined and a larger number of
hazardous events are defined that may lead to
a hazard occurring.
- In relation to requirement c) in the list above,
different approaches exist, e.g.,:
o Detailed calculation by Fault Tree Anal-
ysis to determine frequencies (and con-
sequences) for the sequence of events
(causes) associated with each hazard.
o Engineering judgement of the conse-
quence and frequency of the sequence
events associated with each hazard.
- In relation to requirement f) in the list above, a
number of hazardous events may be controlled
by instructions in manuals, operational rules,
traffic rules etc. A potential challenge may be
to safe guard that future changes within manu-
als, operational rules, traffic rules do not nega-
tively affect risks related to the hazards in the
HL.
- In relation to requirement k) above, it may be
potentially challenging to determine the limits
of analyses and scope of that hazard log when
the system is complex and when there are a
number of actors involved. Each actor may
have different responsibilities in terms of de-
velopment of the system (for example differ-
ent actors developing different parts of the
system) and the operational aspects of the sys-
tem. In certain cases there may be several
HLs that need to interact, e.g. the different ac-
tors may each control their own HL.
Compared to EN 50126-1, CSM regulation pre-
sents the requirements to the HL (hazard record) on
a more generic level. It states that:
- Hazard record(s) shall be created (or updated
where they already exist) by the proposer dur-
ing design and implementation until ac-
ceptance of the change or delivery of the safe-
ty assessment report. A hazard record shall
track the progress by monitoring risks associ-
ated with the identified hazards. Once the sys-
tem has been accepted and is in operation, the
hazard record shall be further maintained by
the infrastructure manager or the railway un-
dertaking in charge of the operation of the
system under assessment as an integrated part
of its safety management system.
- The hazard record shall include all hazards, to-
gether with all related safety measures and
system assumptions identified during the risk
assessment process. It shall contain a clear
reference to the origin of the hazards and to
the selected risk acceptance principles (three
principles in the CSM regulation: application
of codes of practice, comparison with refer-
ence systems and explicit risk estimation) and
clearly identify the actor(s) in charge of con-
trolling each hazard.
- All hazards and related safety requirements that
cannot be controlled by one actor alone shall
be communicated to another relevant actor in
order to find jointly an adequate solution. The
hazards registered in the hazard record of the
actor who transfers them shall only be re-
garded as controlled when the evaluation of
the risks associated with these hazards is
made by the other actor and the solution is
agreed by all concerned.
When comparing the requirements to the HL
from EN 50126-1 and CSM as presented above, it
appears that the communication aspects when sever-
al actors are involved and the responsibilities of the
HL are to a larger degree covered by CSM than EN
50126-1.
The AHL has to satisfy the relevant safety stand-
ards so the requirements for an AHL and an ordinary
HL are more or less the same. It is the processes that
are different. For the AHL, it is recommended to in-
clude all the hazard log requirements from the safety
standard EN 50126 together with communication
aspects included in the CSM regulation, which also
corresponds perfectly with the Agile mind set.
4 REUSE OPPURTUNITIES AND TEMPLATES
Much of the work invested in generating a hazard
log can be reused in later hazard logs. Reuse of in-
formation and documents and the use of templates
have several benefits – e.g.
 Increased productivity of information and doc-
uments
 Reuse of documents and information available
as part of the tools
 Reduce effort of making HLs
 Move information and documents more easily
among projects and different products
 Quick and effective process when developing
new documents
Reusable information could be included in a
DOORS database or similar, while relevant docu-
ments are e.g. PHA (Preliminary Hazard Analysis)
and safety stories.
If a safety product, for which a HL already exists,
is modified, the new HL can be based on the existing
one. We mainly need to argue for the changes and
their effects. This is considerably less work than
producing a new HL every time.
Reusable information and documents have low
extra costs when developed and low cost when re-
used. This is information or documents where parts
are reused as is, while remaining parts need to be
adapted for each project. This holds e.g. even for
each sprint for some documents. If we think reuse
right from the start, the changes between projects or
iterations will be reduced. The reusability opportuni-
ties will increase if we use generic failure modes.
When doing modification of an already certified
product, only a few documents are new – see
Myklebust et al (2014) – e.g. documents required for
new tools that may introduce hazards. These new
documents should be based on templates or reuse of
similar documents or be automatically generated to
reduce the documentation costs further.
The development of new documents carries a
high costs. It is therefore beneficial to make use of
available templates that have been published as in-
dustry papers, e.g. "change impact analysis" Mykle-
bust et al (2014) or published by organizations de-
veloping guidelines like e.g. Misra
(www.misra.org.uk) and AAMI (www.aami.org).
It is an important part of the SafeScrum mind set
to reduce the amount of documentation and the as-
sessor should be involved early in the project to dis-
cuss the level of information that need to be deliv-
ered to the assessor. The assessor may have access
to the HL database itself or printouts from the HL
database. Which documents the assessor needs,
should therefore be discussed before starting to de-
velop any new document.
Experience has shown that it is beneficial for the
assessor to have access to this kind of information
from the assessor's premises rather than requiring
the assessor to be present at the manufacturer's
premises. However, the assessor could review some
of the information, as part of audits and technical
meetings.
5 THE AGILE HL PROCESS FROM SYSTEM
DEFINITION TO THE AGILE SAFETY CASE
The Agile HL process that we have developed is il-
lustrated in Fig. 4. These agile adaptions have been
developed without compromising the requirements
given in EN 5012X and IEC 61508.
First, we describe the activities and the necessary in-
formation.
System definition:
The system definition is an important document for
developing both the hazard log and the safety case.
The system definition is also important for the pro-
duction of evidence to be included in the safety case.
With a frequently changing world, the system, and
thus the system’s definition, will also have to be
changed frequently. One way to handle this is to
change from a waterfall process to an agile process.
The Agile Safety Plan:
A safety plan is required by EN 50126, but is not re-
quired in IEC 61508. The Agile Safety Plan has
been described by Myklebust et al in (2016). The
Agile Safety Plan satisfies the EN 50126 require-
ments and at the same time enables an agile devel-
opment process.
Preliminary Hazard Analysis (PHA):
There exist several techniques to help in hazard
identification performed as part of e.g. the PHA. Use
historical safety experience and hazard logs, lessons
learned, trouble reports, hazard analyses, and acci-
dent and incident files. When an acceptable edition
of the "Definition of system" to be evaluated exists,
the hazard identification may start.
SRS:
The specification of the safety requirements is part
of phase 4 in both EN 50126:1999 "system require-
ments" and IEC 61508-1 "overall safety require-
ments". The "System Safety Requirements Specifi-
cation" and the "Software Requirements
Specification" are two of the requirement documents
listed in EN 50128:2011.
Alongside activities:
The AHL is developed alongside the software de-
velopment. Alongside development is activities per-
formed outside but alongside the sprints. This work
can be time-boxed together with the Sprints. The
development of the AHL should preferably be
planned together with other alongside activities like
the development of the Agile safety case Stålhane
and Myklebust (2016) and independent tests. This
activity is performed by e.g. independent testers,
safety analysts, safety responsible and safety case
author. This is important to ensure a coordinated de-
velopment.
Safety stories:
Safety stories have been described earlier by both
Myklebust et al (2016) and Paige et al (2011). Safety
stories is a safety practice developed to ensure that
the agile requirements management process encom-
pass the safety requirements together with required
measurements and techniques. The safety story card
will create a common problem understanding be-
tween the software developers and the safety stake-
holders. Safety stories are stored in the safety-part of
the product backlog
Safety stories are user stories that include one or
more safety requirements.
Figure 4. The Agile HL approach): Process from system defi-
nition to the Agile Safety Case. The numbers with black back-
ground corresponds to the phases in IEC 61508 safety lifecy-
cle.
6 RELEVANT AGILE PRACTICES
A practice in software development is a working ac-
tivity. In order to be a practice, it must be repeatable.
In this paper, we have limited the practices to agile
practices but some of them may also be used when
following a waterfall/V-model approach.
We have evaluated the most important agile prac-
tices for Safety Critical Software (SCSW) and de-
scribed adaptations of three of them.
The top three practices was established as a com-
bination of the most frequently used practices and
our evaluation of how the practices fit into develop-
ment of safety critical software and ensures an im-
proved hazard log process together with an im-
proved hazard log.
"Backlog" together with "backlog splitting":
Often there are different formats of the product
backlog and the Sprint backlog. A backlog is gener-
ally seen as a list of requirements which includes
e.g. safety stories (features, safety requirements and
technical tasks) which the Sprint team and those per-
forming the alongside activities maintains and
which, at a given moment, are known to be neces-
sary and sufficient to complete a project or a release.
If an item in the backlog does not contribute to the
project's goal, it should be removed. The backlog is
the primary point of entry for knowledge about re-
quirements, and the single authoritative source de-
fining the work to be performed.
"Backlog splitting" as a practice was introduced
as part of the introduction of SafeScrum Stålhane et
al. (2011). In SafeScrum, all requirements are split
into safety critical requirements and other require-
ments and inserted into separate product backlogs.
Alternatively, the safety requirements are tagged.
Adding a second backlog is an extension of the orig-
inal Scrum process and is needed to separate the fre-
quently changed functional requirements from the
more stable safety requirements. The backlog does
normally not describe every item at the same level of
detail. Features and tasks which are expected to be
delivered in the near future, should be broken down
into fine-grained items and accompanied with details
such as acceptance tests. The staffing of the Sprint
team and the duration of the sprint, together with es-
timates of each item decides which items that can be
selected for development. The alongside activities
and the team performing the alongside activities may
also have an effect.
The backlog that originally was developed for the
software engineers may greatly help in the under-
standing of the requirements and as a result ensure
that requirements are implemented correctly. The
SRS is often difficult to understand for a software
engineer so the process and practices introduced by
the agile community are helpful for the developers.
E.g. it is difficult to understand since an SRS may
state that the product shall satisfy IEC 61508 and
nothing more. The Backlog may then help the SW
designers to introduce less hazards.
"Backlog refinement meetings":
This practice is also known as backlog grooming.
Story time is a similar practice.
Backlog refinement as defined by
www.agilealliance.org/glossary/backlog-
grooming/ (slightly modified and added safety
aspects by the authors) is defined, in an agile ap-
proach as: When the product owner and some, or
the rest of the team, review items in the backlog
to ensure the backlog contains the appropriate
items, that they are prioritized, and that the items
at the top of the backlog (most important) are
ready for delivery - i.e., implemented (then they
are not in the backlog anymore). This activity oc-
curs on a regular basis and may be an officially
scheduled meeting or an on-going activity.
Especially, there will normally be several such
meetings in the first phases of a project. Some of
the activities that occur during this refinement of
the backlog include removing user stories that no
longer appear relevant, creating new user stories
in response to newly discovered need and re-
assessing. We also need to consider the relative
priority of stories, assigning estimates to stories
which have yet to receive one, correcting estima-
tes in the light of newly discovered information,
splitting user stories which are high priority but
too coarse grained to fit in an upcoming iteration  safety- and user stories, increments (may include
The backlog refinement is important to fully under-
stand the safety requirements. The RAMS or e.g. the
safety manager may be involved in the backlog re-
finement meetings to ensure vital safety feedback. If
in doubt regarding safety requirements related to
legislation or standards, the assessor should be con-
sulted ASAP.
The backlog refinement meetings may improve
the understanding of the requirements and as a result
ensure that requirements are implemented correctly.
"Sprint Review":
also named Demonstration Meeting and Sprint
demo. The Sprint Review takes place at the end of
the Sprint and is designed to gather feedback on
what the team has completed. This practice is a good
opportunity for the team to show its work and to in-
spect the overall aspects for the product backlog.
In SafeScrum, after a planned number of sprints
Myklebust et al (2016), the project should deliver a
potentially reviewable product increment. This
means that at the end of each incremental sprint
(may have several iterative sprints before an incre-
ment), the team has produced a coded, tested and re-
viewable piece of software. In an iterative sprint be-
tween each increment they demonstration can be
anything that can be explained and discussed in rela-
tion to a story/requirements. The RAMS responsible
person or e.g. the safety manager may be involved in
the sprint review to ensure safety feedback. The
demo is a practical approach to ensure that design
errors are discovered and that the original intent of
the requirement is implemented. Implementation er-
rors can also be errors due to the tools, use of the
tools, coding and models. Already implemented po-
tential hazards may thus be revealed at the earliest
possible time.
According to Kniberg (2015): "A well-executed
sprint demo, although it may seem undramatic, has
a profound effect: The team gets credit for their ac-
complishment. They feel good. Other people learn
what your team is doing. The demo attracts vital
feedback from stakeholders. Demos are (or should
be) a social event where different teams can interact
with each other and discuss their work.
This is valuable. Doing a demo forces the team to
actually finish stuff and release it (even if it is only
to a test environment). Without demos, we kept get-
ting huge piles of 99%-finished stuff ".
In relation to performed sprints, Sprint Review,
sprint demo and the delivery of increments,
SafeScrum has defined a criteria for "Definition of
Done". This definition includes a definition of done,
when the product or system shall be placed on the
market. SafeScrum's incremental lifecycle delivers
new functionality in small bits at a time through
several iterations/sprints), and releases.
To align SafeScrum with regulations and safety
standards, Done-ness criteria have also to address:
 The alongside activities that must be com-
pleted during and after the last Sprint. This
includes V&V activities and information and
documents to be produced including delivery
to the relevant parties involved
 Authorization and the required documenta-
tion in that context for some domains like
e.g. the Railway domain
7 CONCLUSION
The Agile HL approach takes the best from the two
worlds: conforming to safety standards and agile
processes and practices. We have presented recom-
mendations for the AHL requirements: it is recom-
mended to include all the hazard log requirements
from the safety standard EN 50126-1 together with
communication aspects included in the CSM regula-
tion, which also corresponds perfectly with the Agile
mind set. A safety process has been suggested in-
volving amongst other things, safety stories,
SafeScrum and alongside engineering. Adaptation
of the agile practices as follows may result in further
improvements of the process: backlog together with
backlog splitting, sprint review and backlog refine-
ment.
The AHL approach further represents an im-
proved process, e.g., by being suited for frequent
changes, for the development and maintenance of
the HL. The process is especially improved in rela-
tion to the stronger emphasis on software develop-
ment.
This work has also shown that there exist possi-
ble improvements of IEC 61508-3, by requiring the
use of hazard log as a single source of risk manage-
ment activities. This task performed by the validator
could preferably also be required in the IEC 61508
series without requiring who shall perform the task:
"the validator has to ensure that the related hazard
logs and remaining non-conformities are reviewed
and that all hazards are closed in an appropriate
manner through elimination or risks control/transfer
measures."
Acknowledgements: This work was partially
funded by the Norwegian Research Council under
grant #228431 (the SUSS project) SINTEF SEP pro-
ject "Safe Software" and "The Agile Safety Case"
project.
T. Myklebust, G. K. Hanssen and N. Lyngby. A survey of
the software and safety case development practice in the
railway signalling sector. To be presented at ESREL 2017
R. F. Paige, A Galloway, R. Charalambous and X. Ge.
High-integrity agile processes for the development of safety
critical software. Int. J. Critical Computer-Based Systems,
Vol.2, No. 2, 2011
Kelly T. Software Certification: Where is Confidence Won
and Lost? SSS2014
T. Myklebust, T. Stålhane and N. Lyngby. The Agile
Safety Plan. PSAM13, 2016 Seoul.

8 REFERENCES

Commission implementing regulation 402/2013 of 30 April

2013 on the common safety method (CSM) for risk evalua-
tion and assessment and repealing Regulation 352/2009

COMMISSION IMPLEMENTING REGULATION (EU)

2015/1136 of 13 July 2015 amending Implementing Regu-
lation (EU) No 402/2013 on the common safety method for
risk evaluation and assessment

EN 50126-1:1999 Railway applications – The specification

and demonstration of Reliability, Availability, Maintaina-
bility and Safety (RAMS)

IEC 61508:2010 series. Functional safety of electri-

cal/electronic/programmable electronic safety-related sys-
tems.

Myklebust T., Stålhane T., Hanssen G. K. and Haugset B.

Change Impact Analysis as required by safety standards,
what to do? PSAM 12 Hawaii 2014

Myklebust T., Stålhane T., and Hanssen G. K. Use of Agile

Practices when developing Safety-Critical software. ISSC
2016-08, Orlando.

T. Myklebust, T. Stålhane and N. Lyngby. The Agile Safe-

ty Plan. PSAM13, Seoul.

T. Myklebust and T. Stålhane. The Agile Safety Case.

SafeComp 2016-09, Trondheim.

Kniberg H. Scrum and XP from the trenches. How we do

Scrum. Second edition 2015.

T. Myklebust and T. Stålhane. Safety stories – A New Con-

cept in Agile Development. SafeComp 2016-09, Trond-
heim.

Hanssen, G.K., Haugset, B., Stålhane, T., Myklebust, T.,

and Kulbrandstad, I. Quality Assurance in Scrum Applied
to Safety Critical Software. In proceedings of International
Conference on Agile Software Development (XP). 2016.
Edinburgh, UK: Springer: p.92-103.