How you manage risks in Scrum in real practice? [closed]

Question

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?

Answer 1

Risks are risks no matter what you use to build your software. A risk is a possible future situation that if it is to occur (or maybe not occur) it can negatively affect the project/product in some way. So the traditional knowledge of managing risks apply to Agile or Scrum development also. There is risk identification, there is risk analysis, there are mitigation plans, etc. The difference is in how you deal with these risks.

You still need a risk repository to keep track of the risks, you still need to evaluate risk on the overall product, not just for each iteration or a few iterations. The key thing with Scrum is that you do that with each small iterations, as opposed for example to more traditional sequential processes that occur in larger stages, or at the beginning of the project.

With Scrum, you identify, analyze and respond faster to risks because of the nature of the development, (I already mentioned) short iterations, daily inspection points, sprint inspection points, having to deliver working software after each iteration, which forces you do deal with assumptions and risks sooner, better prioritization, etc.

The real practice of using the risk repository is then tied to the refinement activity. When detailing and prioritizing your product backlog items you need to account for the risks. This might mean including some work in the next sprint to mitigate a risk, or adapting some of the team practices, or improving the way certain things are done, or even accepting the risk and moving on. It also means keeping the risk repository up to date with feedback from sprint reviews and retrospectives. Your risks are part of your product backlog, either as items that you work on, or as a source of data for properly organizing the backlog.

Answer 2

There are a few answers to this because there are different types of risk:

For discrete risks like "X may not be compatible with Y" we would add items to the backlog to address them. Those risks can be prioritized and resolved.

For passive risks, a traditional risk register is just fine. This is usually a better approach than a backlog item because things like shifts in the market, competitors releasing new features, etc, are all things that you are constantly looking out for instead of taking action once.

As one comment mentions, risks to the structure of the project including scope changes are often non-concerns in Scrum projects because we expect the structure and scope of the work to change as we learn more about them.

Answer 3

The product backlog is the place for risks and issues in Scrum: "As a xxxx I want yyyy to mitigate the risk of zzzz". The product owner decides on the relative priority of risks alongside other items on the backlog. When they are taken into a sprint the risk stories get actioned by the team.