What is a Risk?

A Risk is an uncertain event that could impact your chosen path should it be realised.

Risks are events that are not currently affecting you – they haven’t happened yet.

Once a risk is realised, it has the potential to become an Issue.

Aim of Risk Management

1) Prevent the realisation of a risk or

2) to minimise/manage/neutralise the impact of this risk once it has been realised.

If you succeed in point 2 then the net impact of realizing the risk may be totally acceptable i.e. no issue at all.

Risk Management for Projects

Agile Risk Identification

Agile Risk Assessment

Agile Risk Response

Agile Risk Review

Agile Risk Management – Identifying Risks

• In Agile environments, the team shares responsibility for identifying risks that might affect a sprint, project or programme of development.

• The Scrum meetings provide a

strong forum for identifying risks on a daily basis.

Identifying Risks(Cont…)

Requirements Workshop: – The team and the Product Manager discuss new ideas and a rough idea of the

effort required to deliver them.

– This conversation allows the Product Manager to re-consider and/or adjust requirements in a way that maximises value and minimises risk/uncertainty.

Planning Poker: – Here the team estimates the relative size of each User Story.

– This is yet another opportunity for a Product Manager and a team to reduce risk by rejecting User Stories over a certain size – they’re either broken down into smaller stories.

Scrum of Scrum: – In this session, we review project-level progress, risks and issues. The session is

attended by the Scrum Master(s), Product Manager and Product Owner(s).

Identifying Risks(Cont…)

Sprint Planning: – Sprint Planning is yet another opportunity for the team to identify, assess and

respond to Risk.

– They only accept work they feel confident about delivering.

The Daily Scrum: – Once the sprint has commenced, the Daily Scrum becomes the main forum for

raising Risks and Issues.

– We ask the question “Is anything blocking you or likely to block you from progressing as planned?”.

– We add highlighted risks to the Risk Board and catch up with the individual after the Daily Scrum to gather more details

Identifying Risks(Cont…)

Sprint Review: – This session also provides an opportunity to highlight successful mitigation

activities – it’s good to keep your stakeholders informed of what’s going on.

Sprint Retrospective: – Retrospective discussions will focus primarily on the idea of continual

improvement and Risks can be unveiled at this session.

– The key questions answered at a retrospective are:

• 1. What went well last sprint? This could be the successful handling of a risk.

• 2. What didn’t go so well last sprint? This could be the realization of a risk or the re-occurrence of an issue.

• 3. What will we do differently next sprint? This could include risk mitigation activities.

Agile Risk Management – Assessing Risks

We use two measures to describe a risk: The probability/likelihood of it being

realized

The impact it will have if it is realized

Assessing Risks(Cont….)

We assess Risks based on their severity.

Let’s take 1 being low impact/probability and 5 being high impact/probability

• A User Story is severely underestimated in the first sprint, compromising the team’s ability to deliver their commitments (1,5)

• A User Story is severely underestimated in sprint 10, compromising the

team’s ability to deliver their commitments (5,1)

Agile Risk Management – Risk Response

There are four different categories of Risk Responses 1) Mitigate 2) Avoid 3) Contain 4) Evade

Risk Response(Cont….)

Mitigate: Agile teams employ risk mitigation techniques via their use of ‘Velocity’

– They Stretch Tasks as a way to manage expectations about delivery

capacity – The team commits to less but has a number of additional User

Stories waiting in the wings for them to consume in the event the risk is not realised.

Avoid: This describes a scenario where a project or a part of a project is cancelled in order to remove the threat of realisation.

– As described above, the Product Manager will often remove a User

Story or amend a requirement in order to reduce or remove an element of risk.

Risk Response(Cont….)

Contain: To contain a risk describes a situation whereby you agree to deal with it and when it occurs.

– These risks tend to be low(er) impact and/or less likely to occur thus. – On the other hand, it may be decided that the impact associated with

mitigation or – avoidance would have a greater negative impact than the realisation

itself. In other words you are prepared to take the risk.

Evade: To evade a risk means to take no action at all. – The risks which warrant this type of response are likely to be low

impact risks, whose realisation would have little to no effect on project or company objectives.

Agile Risk Management – Risk Review

Risk Review is the final stage in the Agile Risk Management process.

Risk Review(Cont….)

The ‘Review’ stage in the Risk Management life cycle is three-fold:

– Reviewing active risks to ensure that responses are delivered in a timely/efficient manner

– Reviewing the risk management process to ensure that it is optimised

– Reviewing the impact of risks and risk realisation on project and company objectives

Agile Issue Management

Agile Issue Management

• Scrum is great at handling immediate issues they’re more commonly referred to as ‘Impediments’.

• Team raises issues daily via the Daily Scrum.

• Some teams like to keep track of all of these impediments by using an Issues Snake or an Issues Calendar.

How this works ?

• Every time an issue is raised at the Daily Scrum, you write it on a post-it and place it somewhere visible.

• If the same issue is raised more than once, you add another post-it-note to the board.

• This helps to keep track of blockages and disruptions and can be used to drive conversation at the end-of-sprint Retrospective or at the end-of-sprint Review.

• This approach also helps you to quickly identify re-occuring issues/blockages.

Issues Calendars

Issues Calendars are particularly useful as you can compare them to the team burndown to better understand velocity variances e.g. ‘the team burndown suffered on that day as they were dealing with a particularly hefty impediment.’

Issues Snake

This is another way of maintaining the daily issues

Agile issue management Vs. Traditional issue management

• Agile Issue Management is built into the delivery process- e.g. Daily Scrum

• The Team works together to raise and clear issues

• Documentation is kept to a minimum – all energy is put into clearing the issue

• The team regularly reviews their issue management approach in hopes to improve their handling techniques