16 Dec, 2021
Lotte, Digital Content Specialist

Get the latest updates about our blog posts.

Subscribe so you don’t miss out!

The world of mobile application development is ever-growing, and with every app we build with our clients, we have to make sure that the value of the product and features are worth the risks that come along with it. We do this by implementing a so-called value/risk matrix starting in the early stages of our partnerships. Together with our clients, we dive into the details of the product in order to assess and analyse the risks involved as well as prioritize the most important elements of their solution. In this article, we tell you all you need to know about the value/risk matrix and its crucial role in SCRUM and the app development process.

The value/risk matrix

The value/risk matrix, also known as a risk assessment matrix, is a tool we use in our app development process to evaluate the complexity of an app based on its value and risk. It’s a crucial aspect of the decision-making process. Before diving into a new project, we identify the main objectives, order and prioritize assets, define risks, assess risks, analyze risks, set risk tolerance levels, and discover solutions to mitigate risks as part of the risk management process.

Regardless of the use, the risks and values that are involved in a project or initiative are displayed in the matrix. This allows organizations to filter and rank each action and prioritize investment decisions that are aligned with the organizational objectives. In this blog, we zoom into the third example of the implementation of a value/risk matrix: the prioritization in product roadmaps of app development projects.

How does it work?

As pictured in the image above, the value/risk matrix can be visualized as four different segments, with the risk on the X-axis and the value on the Y-axis. If we assess a score of 100 as our maximum number, a low-risk initiative will score between 0 and 50, and a high-risk initiative will score between 50 and 100. Depending on the score of an item on the value/risk matrix, you can assign a level of priority, for example:

  • High-value & low-risk items should get the highest priority.
  • High-value & high-risk items might be worth the effort, but we need to re-analyze and perform additional risk mitigation if possible.
  • Low-value & low-risk items can be worthwhile in the long run, but they should always be prioritized below high-value items.
  • Low-value & high-risk items should be avoided, unless it’s a crucial element, such as a Cookie Policy pop-up. While this does not add much value to the customer, it is a lawful requirement.

While there are several methods to perform a value/risk assessment, here’s one example of a step-by-step approach to creating a value/risk matrix:
  1. Start off by listing all the items that need to be evaluated, such as specific processes or product features.
  1. Assign a value to each of these items based on its eventual predicted value/usefulness to the business and customers.
  1. After assigning a value to each item, it’s time to evaluate the risks. Here, we analyze every item on the list regarding uncertainties around costs, time, execution, complexity, etc. We normally measure three main risk areas:
    • Financial risk: not worth the money
    • Development risk: too technically complex, not feasible within a certain amount of time of budget
    • End-user risk: the user won’t be using it
  1. With the assigned values and risks in mind, apply the scores to the value/risk matrix to get a visualization of the assessment and use that to create a plan of action.

The benefits of a value/risk matrix

You might wonder if it’s going to be worth it to spend your time, money, and effort on a specific feature of your application. The value/risk matrix is designed to answer that question, and includes several benefits:

  • You can efficiently list all the risks involved with a deeper understanding of their impact on your product or business. With an overview of all these potential risks, you can make sure to keep the items with the lowest risk at the top, and not spend too much time and effort on higher-risk items.
  • By prioritizing the higher value, lower risk items, developers spend more time on optimizing and perfecting essential, high-value items.

  • You avoid investing too much money and effort into a specific functionality or feature that won’t add value to your customers in the end.

  • You can set up strategies beforehand in order to prepare for the unexpected. While it’s impossible to fully prepare for everything that can go wrong, considering and assessing the potential risks involved in your project gives you the opportunity to prepare action plans in case something goes awry, increasing your chance of success.
  • If a potential risk actually occurs, you can greatly reduce or even neutralize the impact of it if it’s caught early.

Using the value-risk matrix at Lizard Global

At Lizard Global, the value/risk matrix is deeply ingrained in our agile and scrum development process. We usually start projects by diving into the broader themes and epics of a product, rather than detailed user stories. Epics should be based on the complex objectives of a project, which will take a core role of each sprint release. Before we define a high-level matrix, we split the epics into smaller stories. We evaluate these stories on their values and risks and apply them to the matrix. We then define priority in the order of:

  • Prioritize (high value, low risk)
  • Investigate further (high value, high risk)
  • Consider (low value, low risk)
  • Avoid (low value, high risk)

As the name implies, a “Prioritize” item will definitely take part in the sprint. Investigate Further means we need to try breaking the story down into smaller stories and reapply the matrix. Repeat until you have a sufficient number of stories to prioritize.

Read more about Themes, Epics, and User Stories in our blog on User Story Mapping! Click here to check it out!

At Lizard Global, our entire development methodology is built on the principle of adding value in each sprint release. In this process, the Product Owner is responsible for continuously maximizing the value that the development team delivers. He/she does this by applying design thinking principles to create a deep understanding of the client’s business and end-users to eventually be able to define different types of business values:

  • Commercial: a functionality that directly translates into profit, such as IAP to generate income, optimizations and automation to reduce costs or features that add subjective value to the product.
  • Market: a functionality that increases the potential number of users, like social sharing features to engage new users.

  • Efficiency: a functionality that increases organizational efficiency and thereby decreases operational costs. Think of the automation of data transfers and or recruitment processes to reduce the load on support desks.

  • Customer: a functionality that makes users come back to the application (stickiness), such as push notifications or new features based on user feedback.

  • Future: a functionality that benefits future features and optimizations. For example, upgrading frameworks or optimizing the level of scalability for future growth.

The MoSCoW Method

Aside from risk and value, there is an additional way to prioritize an item above another. For example, priority can be established by law or by the needs/wishes of the customer. At Lizard Global, use "MoSCoW" to specify a priority, and it has the power to override the results of the value/risk matrix. MoSCoW is an acronym for “Must, Should, Could, and Won’t”, and prioritizes items that are absolutely critical for an application to function, all the way down to the items that aren’t worth including in the product. Eventually, we have finalized a high-level overview of the product and its items, consisting of the following information:

  • Priority
  • Value
  • Risk
  • Size of project estimation
  • Sprint week
  • Assigned developer

Need a hand?

Do you want to know more about how we implement the value/risk matrix and the MoSCoW method in our development processes? Or do you want to start your own project with us to find out if your product and its features are worth the investment? Click on the little present on this page and schedule a free consultation session with our experts in the field!

Frequently asked questions



What is a value/risk matrix?

The value/risk matrix, also known as a risk assessment matrix, is a tool we use in our app development process for evaluating the priorities and complexities of an app based on its value and risk.


How is a risk score categorized?

The value/risk score can be divided into four categories:

  • Prioritize (high value, low risk)
  • Investigate further (high value, high risk)
  • Consider (low value, low risk)
  • Avoid (low value, high risk)


What are the benefits of a value/risk assessment?

  • You can efficiently prioritize the most important tasks for your project based on their level of risk and value
  • Developers end up with more time to optimize high value items during the development process
  • You avoid investing time and money on items that won’t result in much value for your customers
  • You can prepare strategies to prepare for the unexpected
  • If a potential risk occurs, you can greatly reduce or even eliminate the impact it has on your project


What is the MoSCoW method?

MoSCoW is an acronym for “Must, Should, Could, and Won’t”, prioritizes items that are absolutely critical for an application to function, all the way down to the items that aren’t worth including in the product.
An image of markus at the blog page

Hey there, can I help you?

Did you like the blog above, but do you still have some questions about the subject or related topics? No issue! You can easily contact one of our Lizard specialists on these specific topics, and they gladly tell you more about it. This way, you’ll never leave with uncertainties.


Global Commercial Director | markus@lizard.global | +60 18 35 65 702

Similar Articles