Risk Management in scrum

Scrum's risk management is handled via its sprint timebox.  A sprint can run for 30 days or less.  The more risky the PBI, the shorter the sprint should be. 

Risk management is the process by which an organization identifies, evaluates, prioritizes, and mitigates deviations from expected outcomes.

The Scrum Guide says that:

Scrum employs an iterative, incremental approach to optimize predictability and to control risk.

Risk management isn't clearly spelled out in the Scrum Guide, but there are few examples to see it in practice.

Scrum helps a team mitigate schedule and budget risks by establishing a stable team, a regular cadence, and frequent delivery of a usable product. With a stable team, it's easier to estimate costs. With a regular cadence and frequent delivery, the team is capable of putting something into the hands of users on a regular basis and getting feedback. The stakeholders know that they will very likely get an improved product at least once a Sprint and how much each Sprint is costing them. This allows them to determine if it's viable to proceed based on the team's performance, realized value, and potential value in the Product Backlog.

If the team is truly embracing agility, they are also able to mitigate risks around quality and defects. The Definition of Done sets a clear bar for the quality of all work that is integrated into the product. Even if defects do slip through, the highly iterative nature of Scrum allows for teams to adjust their backlog and address issues fast enough to meet customer demands.

Depending on the context, there may be risks around uncertainty in the tools and technology used to build the product or provide the service. Incremental development lets the team build and prove small slices, obtain feedback, and continuously improve the product. The feedback can come from the team itself as they learn the domain, the product, and the tools. The feedback can also come from stakeholders as they use the product.

Unfortunately, it's tough to get into specifics unless the organization has identified some of its risks. It's likely that following Lean and Agile principles and using the practices and structures in the Scrum framework will help the organization to find opportunities to mitigate many risks.

Do keep in mind that, like many things in Scrum, risk management is not the responsibility of the Scrum Master. The Scrum Master should be in a position to help the team watch for risks, coach them on methods to identify and evaluate risks. However, risk management is a whole-team activity. Some risks may also extend beyond the Scrum Team and across the organization.

What is Risk management in scrum and how scrum master mitigate these risk ? 

Every time an investment is made without receiving immediate value, a leap-of-faith is being taken and a certain risk is being incurred.

If you were a Scrum Master, how would you recommend that this risk be managed?

Risks are strong related with uncertainty, so to manage risks it is necessary to identify uncertainties.

Interesting discussion, I would like to add some thoughts.

When the Scrum guide talks about control risks, which risk is meant? Any risk? I think complexity carries risk (and unpredictability) in it, such as the risk of changing requirements. This risk is mitigated by Scrum "as an iterative, incremental approach".

But what about the concrete risks beside the complexity. Example: If we decide to shift our implementation into cloud, will we be able to handle the upcoming traffic? So who has a vested interest in mitigate that risk? My understanding (and most cases I can think of) it is the product owner. As written in the scrum guide:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team

And risk, in the end (might) decrease this value.

I agree that the Product Owner has some accountability for risk.  But the whole Scrum Team is accountable for the risk.  The Product Owner does not dictate the technical implementation. So while a change that the Product Owner identifies as a priority for the product may not seem risky on the surface, the Developers may see it differently based upon the technical implementation. The Developers bear the accountability for their chosen implementation. 

The Scrum Master has some accountability for risk as it is their role to guide the entire Scrum Team in transparency of information.  In the above example, if the Developers do not feel safe in voicing their concerns and the Product Owner is not comfortable letting that information out to the wider organization, the Scrum Master is not doing their part in coaching the team or organization. 

There is inherent risk in any change.  The way that Scrum helps to mitigate it is by being open with information, encouraging experimentation that can be quickly examined for adjustments, and being able to make those adjustments quickly. 

Remember that empiricism is the heart of Scrum and agility in general.  If you are not willing to take a risk to make a change, then you will never be able to learn from it and adapt is necessary.  The key is how fast you are able to adapt if needed.