Agenda
✓ Risk Management in Agile
✓ Agile Risk Adjusted Product Backlog
✓ Agile Risk Management
✓ Risk Identification
✓ Risk Assessment
✓ Risk Response
✓ Risk Review
✓ Agile Risk Burndown Chart
✓ Agile Risk Profile Graphs
✓ Progressive Risk Reduction Steps
✓ Agile Risk-Based Spike
✓ Quiz
Risk Management in Agile
image Courtesy : LeadingAnswers.com
Risk Management in Agile
The risk management process is repeated every iteration. As part of the iteration
retrospective, the remaining risks can be reviewed and the probabilities and
impacts validated. The team can be asked to identify new risks and remaining
features that still carry risk identified for selection in the next iteration.
Risk Adjusted Product Backlog
• The product backlog is continually analyzed and adjusted.
• The customer, often with an analyst and perhaps other team members,
prunes the backlog.
• When pruning, impact (risk) analysis is key: Items are broken down,
analyzed for their interdependencies, shifted up or down in priority, re-
estimated, removed, and reallocated to iterations or releases. This happens
weekly on most agile teams.
• Analyzing the impact of changing requirements is part of the rhythm of
successful agile teams.
Agile Risk Management
1. Identify
2. Assess
3. Respond
4. Review
Risk Identification
The team shares the responsibility to perform risk identification using
information gathering techniques such as checklists, document reviews,
assumption analysis, and various others to identify project risks and record
them in a risk register/spreadsheet
Risk Identification
Risk is identified at following stages,
• Requirements Gathering
The team and the product manager discuss new ideas (rough idea of the effort required) and this allows them to
reconsider and/or adjust requirements in a way that maximizes value and minimizes risk/uncertainty
• Planning Poker
At this stage, the team estimates the relative size of each user story. Here, the product manager and the team
can reduce risk by rejecting user stories that are over a certain size as uncertainty increases as the
size of the size of user story increases.
• Iteration Planning/Sprint Planning
During the iteration planning, the team identifies, assesses and responds to risk. They only accept work they feel
confident about delivering – they will work with the product manager to maximize output in a way
that reduces risk of failure.
• Daily Scrum
During the daily Scrum meeting, risks and issues are identified. The risks are added to the risk board and the
agreed response plan is documented.
Risk Identification
• Iteration/Sprint Review
During the review session, risks are discussed - successful
mitigation/evasion activities are highlighted and information shared with
stakeholders too.
• Iteration/Sprint Retrospective
During the retrospective meeting, the team discusses what went well
(which risks were handled successfully), what did not go well (reoccurrence of
risk) and what will be done differently next iteration/sprint (risk mitigation or
response activities).
Risk Assessment - Categories
• Political
P
E • Environmental
✓ Business Risk
S • Societal
✓ Technical Risk
T • Technological
L ✓ Logistical Risk
• Legal
E
• Economic
Risk Assessment: Risk Census
Risk census describes each risk, provides an estimate of how likely the risk is to occur (risk
probability), the impact to the schedule if the risk did occur, and then the expected exposure
to the risk which is the probability multiplied by the size of the loss.
Risk Assessment: Risk Board
This board shows,
• Identified risks
• Probability
• Impact
• Risk response (if applicable)
Image Courtesy : Agile101.com
This board should be reviewed regularly
as part of the daily Scrum and/or as part
of the end-of-sprint/iteration
retrospective.
12 Agile Principles
Risk Burndown Chart
• The risk burndown chart is created by plotting the sum of
the risk exposure values from the census vs. The iterations.
• In the chart, we should see a linear drop in risk over the
course of the project.
Risk Response Strategies
• Avoid
This describes a scenario where a project or a part of a project is cancelled in order to remove the
threat of realization. The product manager will often remove a user story or amend a requirement
in order to reduce or remove an element of risk.
• Mitigate
This response seeks to reduce the impact of risk event should it occur. The greatest example of how
Agile teams employ risk mitigation techniques is via their use of ‘Velocity’ as a way to reduce the
risk of estimation uncertainty. Velocity assumes a degree of predictability in order to work and
needs to be adjusted to accommodate varying degrees of risk.
• Transfer
This response transfers risk to a third party; but some risk (residual risk) still remains which needs
to be handled by the other risk strategies.
• Accept
Accepting a risk describes a situation whereby you agree to deal with it as and when it occurs.
These risks tend to be of low(er) impact and/or less likely to occur thus not justifying any drastic
action in advance.
Risk Review
• Reviewing active risks to ensure that responses are delivered
in a timely/efficient manner - is done via the “Daily Scrum”
and program planning meeting. Actions and decision points
are added to the following whiteboards and reviewed daily
• Reviewing the risk management process to ensure that it is
optimized - this is handled as part of the project retrospective
• Reviewing the impact of risks and risk realisation on project
and company objectives - this is handled as part of the project
retrospective
15
Risk Profile Graphs
• Risk profile graphs are “stacked area graphs” of risk severity. The risk severity scores for each risk are plotted
one on top of another to give a cumulative severity profile of the project. When risks and their history of
severities are displayed like this it is much easier to interpret the overall risk status of the project.
• Risk profile graphs quickly inform stakeholders if the risks are moving in the right direction (downwards) or if
issues and concerns are escalating.
Progressive Risk Reduction Steps
• Identify risks as early as possible
• Continuous risk assessment
• Introduce features to deal with risks
• Early and continuous feedback from team
Risk-Based Spike
Spike is a time-boxed period designated to reduce uncertainty by learning
enough about a feature, technology, or process to better estimate, develop,
or fix an upcoming feature or defect.
• If a spike requires more than minimal time and effort, it should be
made visible by creating a story for it in the product backlog. Since a
spike does not result in development work, it should not be sized.
• Examples of a spike may include root-causing a defect or testing the
feasibility of an algorithm or a third party solution. It may also be used
to explore design alternatives for solving difficult problems
Quiz
1. Which of the following are the steps involved in risk
management?
a. Identify, Assess, Respond
b. Identify, Assess, Respond, Review
c. Review, Identify, Assess, Respond
d. Identify, Review, Respond, Assess
Correct Answer is B.
Identify, Assess, Respond, Review are the steps involved in risk management.
Quiz
2. A graph that shows the risk severity scores for each risk
plotted one on top of the other to give a cumulative severity
profile of the project is known as,
a. Risk graph
b. Risk board
c. Risk profile graphs
d. Risk issue boards
Correct Answer is C.
Risk profile graph shows the risk severity scores for each risk plotted one on top of the
other to give a cumulative severity profile of the project.
Quiz
3. Which strategy seeks to reduce the impact of risk event if it
occurs?
a. Avoid
b. Transfer
c. Mitigation
d. Accept
Correct Answer is C.
Mitigation seeks to reduce the impact of risk event if it occurs
Quiz
4. If the risk probability is 20% and size of loss is 5, what is the
risk census?
a. 100
b. 5
c. 20
d. 1
Correct Answer is D.
Risk census is the product of probability and size of loss. Hence risk census = 20% x 5 =
1.
