BT

Managing Risk with Scrum

by Vikas Hazrati on Jul 29, 2008 |

Risk management deals with reducing the probability and impact of adverse events on a project. Agile software development, due to its iterative nature, implicitly makes risk management a part of the project life cycle. Members of the Agile community discussed whether explicit risk management is required, the ability of Scrum to manage all types of risk and who should do risk management.

Michele Sliger suggested that in Agile software development risk gets addressed all the time as a part of daily stand-ups, iteration planning meetings, release planning meetings, retrospective and review meetings. However, she suggested a structured approach for managing risk. The steps included,

Risk Identification - the whole team does this exercise on an iterative basis. The results are recorded on white boards or flip charts.

Risk Analysis - qualitative analysis using judgment, intuition, and experience in determining risks and potential losses. Short development cycles and constant reviews in Agile, make this feasible and effective. This is different from traditional projects where quantitative analysis is done and numbers are assigned to the damage which can occur.

Risk Response Planning - entire team participates in developing options and actions to reduce threats.

Risk Monitoring and Controlling - risk is monitored and controlling strategies are discussed at the end of each iteration. Risks are monitored on a daily basis too by using information radiators.

Ron Jeffries noted that risks are not blocked items, instead they are on the Scrum master's watch list, as a note for things which could go awry. According to him, risks could be of various forms like content not fabricated, new/unfamiliar technology, geographically dispersed team, interdependence with another project, etc. A Scrum team could sort stories by value and risk and work on the risky stories long enough to correctly identify and mitigate the risk. The risk should be added as a story on the backlog and addressed.

Michael James suggested that a software development process like Scrum takes care of risk early in the project life-cycle. It provides various avenues like daily stand-up, sprint review etc where risks can be brought forward and resolved. According to Michael, Scrum does not require a risk register to be created, however, the risks could be managed by the team on a periodic basis.

On a different note, some Agilists believe that Scrum cannot help with risks which are external to the project. It can help with risks related to change in requirement, lack of communication and under performance by team members. However, risks which are external to the project need more than Scrum to be resolved.

Paul Hudson echoed similar thoughts on the Scrum development group. He suggested that though Scrum can handle most of the risks in a project, however, risks which cannot be handled at a team level cannot be handled with Scrum. He gave examples of some risks like lack of understanding of Scrum at the customer, third party products don’t work as expected, external factors which the project depends on won’t happen in time, data loss or corruption in team systems, customer doesn’t speak with one voice, customer representatives have personal agendas that conflict with project goals etc. in support of his point.

Another strongly debated question in the community is 'Who should be responsible for managing risk?'

According to Michele Sliger, the entire Scrum team owns risk management and they are responsible for mitigating it together.

In a discussion on the Scrum Development group, Ron Jeffries suggested that in 'Scrum terms' it is the product owners responsibility to manage risk. Some members agreed with Ron that the product owner is the best person to decide which risks need to be mitigated, since he understands the business best. The product owner can take inputs from all members of the team but the ultimate responsibility lies with him. Peter Stevens added,

As chief bill payer, the P-O is directly interested in mitigating risk. The Scrum Master and Team should/will help the P-O optimally prioritize the backlog. But since ROI is the responsibility of the P-O and the consequence of risk is cost, it is the P-O's responsibility.

Other members of the group suggested that risk management is a team responsibility and everyone on the Scrum team has to work collaboratively to resolve risks.

Thus there is a difference in opinion on whether all the risks can be managed by Scrum and whether risks should be explicitly managed. Most members of the Agile community agree that project related risks can be managed well with Scrum however, there is a disconnect when the risks are external to the project. Similarly, there is no consensus on who owns risk management. There seems to be a strong indication towards the product owner, however some Agilists believe that risk should be managed by the team as a whole.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

The team already has a lot to worry about already by Eelco Gravendeel

I understand why it would be good if the team handles most of the risk management. However; in my experience the team already has their hands full on managing impediments and just delivering value added work. In many cases therefore you just can't expect the team to completely manage all risks. You can expect the team to handle any "technical" risk, since that might impact sprint outcomes directly. Team superseding risks however is something a team normally doesn't want to be bothered with and will expect some management level person to handle, e.g. the Product Owner.




(I also blogged about risk management vs impediment management some time ago)

Re: The team already has a lot to worry about already by Thushara Wijewardena

As I see , identifying the risks and bringing it to everyone’s visibility is a responsibility of the whole scrum team, but doing the response plan, what to mitigate at what time and what to avoid is totally up to the product owner.
May main issue is being in higher management , getting the visibility of the risks happening in the project organization across many scrum project. At the moment its quite challenging to me and ive given some thoughts to it and implemented a small process of doing it.. which is posted at As I see , identifying the risks and bringing it to everyone’s visibility is a responsibility of the whole scrum team, but doing the response plan, what to mitigate at what time and what to avoid is totally up to the product owner.
May main issue is being in higher management , getting the visibility of the risks happening in the project organization across many scrum project. At the moment its quite challenging to me and ive given some thoughts to it and implemented a small process of doing it.. which is posted at projectized.blogspot.com/2010/02/risk-managemen....

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT