Risk management in Scrum

Can you tell us how you manage risks in Scrum in real practice?

@J REYES JUAREZ RAMIREZ, The Sprint in conjunction with a Sprint Goal is a good example of how risk is limited in Scrum because the Sprint is timeboxed and work that can be completed is limited to that timeframe and to the outcomes of the Sprint Goal. Also, Scrum requires a Done Increment, so that will guide us do just enough so that we don't introduce risk into the Increment and in this regard the DoD plays a role.

Hope this helps.

If there is a risk of investing an entire sprint and not achieving the Sprint Goal, it might be worth performing some kind of early validation of a hypothesis.

For example, your Sprint Goal might be to increase the average spend by customers in your online shop. Before you start redesigning your checkout page, maybe it's better to phone some customers on day 1 and find out whether they need anything else that you sell, and why they didn't buy it from you.

If this invalidates the hypothesis that customers are willing and able to spend more money, the sprint can be cancelled, allowing some time to be recovered, and invested in a new initiative.

Can you tell us how you manage risks in Scrum in real practice? 

Can you see how, in real practice, a Sprint limits the leap-of-faith that must be taken before a valuable outcome is achieved?

What risks are you concerned with?

Short, timeboxed Sprints reduces the risk of long-term schedule estimates. By frequently demonstrating and delivering working software, Scrum reduces the risk that the team won't be able to deliver "on time". The frequent reordering of the Product Backlog gives visibility into the next things that stakeholders can expect in the next Sprint.

Scope creep is mitigated by the Product Owner's management of the Product Backlog, and either reordering work or saying no to proposed changes keeps the team focused on what is truly essential and value-adding.

Technical risks are often mitigated by Product Backlog Refinement. The use of decomposition of work and prototyping, coupled with frequently delivering working software can demonstrate that the team understands the problem and how to apply tools and technology to solve it.

The regular inspection of the process is designed to remove bottlenecks and improve the flow of work from idea to delivery.

Can you tell us how you manage risks in Scrum in real practice? 

You can order your product backlog risk based, the most risky items get highest order, for example. 

I usually work with the Product Owner mainly and based it empirically like what is known so far considering the average velocity of the team, the user stories sized in the PB and the Features (Epic sizes), Use Cases of the business etc.

As the Sprint progresses, we constantly re-evaluate the PB and follow MoSCoW approach. We move what our PO deems to be a nice-to-have to the bottom of PB to as much as possible ensure that we deliver first the work with the most value.

Thanks to all of you for your responses:  Steve Matthew, Simon Mayer, Ian Mitchell, Thomas Owens, Nils Hyoma, Joefrey Bartolome. We appreciate too much your explanations. 

Well, lets start with more specific concepts:

Uncertainties are things that are not known, or known only imprecisely. An uncertainty has an effect which is associated with a risk, that is, an uncertainty has a risk associated. A risk is a negative effect of an uncertainty over the project´s objective.

There are uncertainties of requirements, process, resources, and so on.  Specific risks are: Technical Risk, Cost Risk, Schedule Risk.

Form of documenting a risk: "Given that [CONDITION], there is a possibility of [DEPARTURE] adversely impacting [ASSET], thereby leading to [CONSEQUENCE]."

CONDITION: Key fact-based situation or environment that is causing concern.

DEPARTURE: It is an undesired event that is made credible or more likely as a result of the CONDITION. It is a change affecting the baseline project plan.

ASSET: It represents the primary resource that is affected by the individual risk.

CONSEQUENCE: It describe the impact(s) in terms of failure to meet requirements that can be measured, described, and characterized.

So, based on these concepts, we have the following questions:

What are the more common uncertainties in your agile process?

What are the more common risks in your agile process?

Do you think it is possible to identify risks so early, without impacting negatively the agility?

I'm going to keep this simple but I like to propose simple solutions to those I work with. The very nature of Scrum, and my preferred one week sprints, makes Scrum an effective risk management strategy. Emergence. You will see if something is wrong with the product or the process sooner rather than later.

Agile methods, and Scrum in particular, inherently reduce some of the risks that you mention.

Consider cost risk. Each iteration progresses the product forward. Since each iteration is a fixed cost (you know the duration and the cost for people and equipment for that duration), the question becomes if it is worth it to fund another iteration. In my experiences, these decisions aren't necessarily made on an iteration-by-iteration basis, but in units of time. The further out you go, the harder it is to be sure that you'll continue to get your value worth, but by looking at the current state of the Product Backlog and the value of the items in it, you can get a rough idea of if it is worth the cost of another iteration or two.

Consider schedule risk. Not only does each iteration progress the product forward, but you are given something that is working and usable after each iteration. It's not always possible, but you can reduce date-deadlined work. If you minimize the work that has a deadline on a specific date and get a working product every iteration, you are very likely to have a working product on that date. As you approach that date, you will be able to provide feedback and make adjustments. Depending on how hard the deadline is, you can focus on hitting the deadline with the full planned scope and adjust the scope to get the minimum necessary deliverable by the deadline. There is the risk of simply insufficient time to do the work, but the cost of learning that is likely to be less than heavy up-front planning and realizing this as the deadline looms.

Consider technical risk. If each iteration is demonstrating, and possibly delivering working products, the risk of not being able to accomplish the work is reduced. The team is demonstrating that they understand the tools and technology that is required to solve the problem.

The questions about common uncertainties and common risks are highly dependent on the context of the organization. I'm not sure there's any value in getting into specific risks that other people face, so I'd turn the question back on you. What are your most common uncertainties and risks? How are you using iterative and incremental development to reduce those uncertainties and risks, and also demonstrating that risk reduction to your organization and stakeholders?

As far as early risk identification, yes. Risk management is an ongoing activity. It never ends through the life of the project. Some risks will be able to be identified and mitigated. Others will have to be accepted. Some organizations are in a better place than others to mitigate risks, while other organizations have to accept a lot more and press onward. I would argue that agility makes accepting risks less risky since you can course-correct or adjust as you see them start to materialize.