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?

  • 4
    What sort of risks? For many types of risk such as scope change, the agile approach is not to try and mitigate them, but to provide the ability to react fast when they occur. – user1937198 Jul 24 '20 at 20:38
  • 1
    I'm surprised this was closed. If someone just asked me this out of the blue, it would be really broad, but in a project management context, it seems pretty clear. – Daniel Jul 27 '20 at 3:45
  • 2
    @Daniel As you can see from the edits, this question is inherently list-generating: What are the more common uncertainties in your agile process? What are the more common risks in your agile process? It's not even about the OP's specific process; it invites anecdotal responses from everyone's processes. I think it's off-topic, but the community is empowered to reopen it or discuss it on meta. – Todd A. Jacobs Jul 28 '20 at 21:16
  • 1
    user41262 to improve chances of having the question re-opened (which I already voted to btw), clarify where you got the definitions from (I'm assuming there's an expert in the matter backing them up or else it can give wrong direction to the users answering it). – Tiago Martins Peres 李大仁 Jul 29 '20 at 7:14
  • 1
    Agreed with @ToddA.Jacobs. After the edit, the Question is no longer needing focus, but it should stay closed for being list-generating. Unless there's some database of global project risks I'm unaware of, there's no canonical answer to this Question. – Sarov Jul 29 '20 at 17:36

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.


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.


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.

  • 1
    I'm not sure why this got downvoted. While I think it works better as "As a...I want...so that I can mitigate..." this seems like a reasonable way to capture risk controls. – Todd A. Jacobs Jul 25 '20 at 14:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.