2. 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.

3. 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.

4. Risk Management for Projects
 Agile Risk Identification
 Agile Risk Assessment
 Agile Risk Response
 Agile Risk Review

5. 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.

6. 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).

7. 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

8. 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.

9. 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

10. 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)

11. Agile Risk Management – Risk Response
There are four different categories
of Risk Responses
1) Mitigate
2) Avoid
3) Contain
4) Evade

12. 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.

13. 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.

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

15. 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

16. Agile Issue Management

17. 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.

18. 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.

19. 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.’

20. Issues Snake
This is another way of maintaining the daily issues

21. 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