I’ve often heard people say that Scrum doesn’t care about risk management. No risk logs, no risk-related content during Sprint Review or Retrospective sessions. The Development Team is responsible for the quality of the products produced and the way they do it. There’s a risk right here. Without a specific person responsible for quality, deadline, budget, process … then how risk will be managed in Scrum.

Risks depend on each person’s perspective

We should first find out what risk is. In the Oxford English point word has the following definition:

(Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility.

That is a very broad definition. Each person will have their own explanation. That’s why we all view risks a little differently. Risks also have a lot to do with our own participation. Sometimes one person’s risk, but not another.

Risk is also closely related to the work we do. For a project or product there may be different levels of risk with the rest of the same nature.

The risks are different

In work-related environments we often talk about:

• Financial risk – can we pay for it?
• Business risk – will the product be accepted and used? Did it solve the problem?
• Technical risks – can it be done?

Take control of risk with Scrum

Scrum is a very good method of controlling risk in a number of ways. Below I elaborate on the above risks in the context of using Scrum

Financial risk

When we are about to build a new system or change an existing product, we want to know how much the work will cost. Unfortunately, the complexity of developing these products causes bias and makes it difficult to estimate project costs.

This is often a difficult topic for many people, because the way we run the project (without using Scrum) is firstly setting scope, finances, and human resources. With Scrum, some people say skipping the stage but not really. We build it empirically because it’s the best way to control the future in complex environments.

We define clear roles and responsibilities.

• Set up the role of the Product Owner: The person who controls the budget and planning of the product
• Development Team: a self-organizing group consisting of multi-functional experts who can complete the work from start to finish.
• Ask the Scrum Master to support, encourage the Scrum Team to control the process from experience while coaching the team bit by bit every day

The team will then have to come up with how long it will take them to fulfill the first requests into a specific outcome. The shorter the better, as it saves money. If that time is too long it can lead to wasted on the wrong job.

Often investors fund only a few sprints initially and review the results after each sprint. Talk to the Product Owner and Development Team about the return and return on the investment. This means that the costs are predictable. It is the cost spent on these sprints.

The sooner the first release reaches users, the lower the financial risk!

Business risks

Business risk is when the user is not actually using your product because the product does not solve the problem it should. This happens often. The reason is not that your team is stupid. Everything the team did before is useful (Product Backlog refinements, technical requirements, talking to users, doing surveys …) but ignores the risk of people not actually using the product.

In Scrum, the Product Owner role is to keep in close communication with the stakeholders and the Development Team so that the right fit is inevitable. Review the increments of each Sprint together and make a decision to change or stick to the idea.

The Product Owner is neither a Business Stakeholder nor an analyst. He / she is the sales representative in the team to manage and monitor business risks, creating the best product possible.

When starting to use Scrum remember one very important factor: There are no more “we” and “them”, all working together to solve business related problems.

Technical risks

Technical risks can be divided into two main categories:

• Is it possible to create products with an ROI (Return on Investment) ratio?
• Is it possible to maintain the product during development and after?

These are the most important questions you must ask yourself throughout product development. Every day, the Development Team needs to make a decision about whether to spend time on a feature, the results are worth it with the Product Owner or not? So communication is the key here.

For product maintenance: Always keep the habit of looking for technical problems. Whenever you run into a problem that’s really not good, try to make it better (even if it’s just a little bit).

Back with “Definition of Done” in Scrum, we find it valuable once again. Identifying “Done” is very important to carefully control risks. This can improve both the quality and maintainability of the product. Techniques, tools and improvements are clearly represented in “Definition of Done” to facilitate technical risk testing, validation and control.

Summary: The best way to reduce risk is to get it into the hands of the users of your product quickly.

I remember someone saying:

The day we started to deliver, people stopt asking about our velocity.

Source :