Prioritize your Agile Backlog by value and risk

Agile Inception: A simple tool to value and prioritize the business needs of your stakeholders

In the Agile process, the Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team (Source: Scrum Guide from

By saying this, we also say that we must evaluate the Product Backlog items, developed and maintained by the Squads, Scrum Teams, Feature Teams and other Pizza Teams.

Certainly, but how?

The article that I propose here, as well as the Excel tool that accompanies it and that I use for some years, will help you, I hope in this exercise.

Introduction :

Let’s assume that you have performed the different capture of business needs workshops, which allowed you to initialize or complete your Product Backlog, with clear and concise Backlog Items.

Towards the end of the inception phase of your product release, your project, or during your Backlog refinement rituals, the small Excel tool below, will allow you to list your needs and prioritize them.

Link to Excel Template prioritization by value and risk:

Click on the picture to download


First Method:

Value = Business Profit + Business Prejudice (Risk to Don’ts) combined with the difficulty / risk to be made, through a Value / Risk matrix.
The priority is then defined as follows:

P1: Has a high business value and is complicated to achieve.
P2: Has a high business value and is easy to achieve.
P3: Has small business value but is easy to achieve (Ideal for juniors).
P4: Has small business value that is complicated to achieve: Will never been done.

Second Method

WSJF method of SAFe 4: (Business Profit + Emergency (Time Criticality) + Risk Reduction) / Number of Complexity Points (determined in Planning Poker) = WSJF = Weighted Shortest Job First.

You can use one of the two methods by grouping / disassociating the columns as follows:

You can also use both methods simultaneously: This will allow you a better reflection on the results of obtained prioritization.

In this case sort the sheet according to the column “priority” or according to the column “WSJF”.

During the valuation workshops with the business, stakeholders will have to answer all the questions by topic (in fact, to agree on the correct answer on the dropdown list, and to indicate it to the facilitator of the workshop: The Product Owner): Topics:

– Business profit,
– Business prejudice,
– Emergency,
– Risk reduction,
– Points (obtained in Poker Planning Workshop)

You will notice that the answers to the first 4 questions are valued 1, 2, 3, 5 and 8, which allows you to use the first planning poker cards for your different workshops, and thus make them more fun.


Five workshops are needed because the cast is different for each of them


Prioritize your needs by decreasing priority according to your own judgment of the business value. This will make the workshops more fluid with the business, and may business to identify the MVP (Minimum Viable Product) faster.

Invite the business, the other stakeholders, the senior knowledge workers of your team, a representative of the Enterprise Architecture, a representative of Ops or DevOps, a representative for applicative architecture

Reformulate the story of each business need, and for each of them display the dropdown list of columns:

– Business profit,
– Business prejudice,
– Emergency (for WSJF),
– Risk reduction (for WSJF)

Example :

Encourage discussion among the participants and obtain a consensus on each answer required by the 4 columns mentioned above (At first it will seem a little bit long, but no panic, it will accelerate as the review will go on)

If necessary schedule one or two additional workshops to complete this co-evaluation of the business value (I advise to limit each of the required workshops to 2 hours maximum)

2) Complexity / risk assessment workshop

Invite mainly your team’s experts, a representative of Enterprise Architecture, an Ops or DevOps representative, an application architecture representative

Reformulate the story of each Backlog item, and for each of them ask the participants if it will be complex to build and deliver. Choose the answer by scrolling the dropdown list in the “Manufacturing risk” column. This workshop (usually short: 1 hour) allows to quickly get an idea of the complexity to be done. The question is a little different than the one posed during the planning poker, because it includes the risk to make (mastery or not of a technology, tool etc.)

Encourage discussion among participants, and get consensus on each answer

3) Planning Poker Workshop

Here we see another benefit of planning poker: prioritizing by the cost of the functionality compared to its business value (used for WSJF)

Conduct a Planning Poker workshop, on the whole Backlog, or at least on the MVP, as described by this good old Mike

Do not hesitate to do Story splitting if necessary (divide the initial Backlog item into several Backlog items that will be easier to evaluate), if it appears to be too complex to estimate

4) Sort your Backlog

You are now ready to sort your business requirements according to their calculated priority

Either according to the first method: priority column in ascending order

Either according to the second method: WSJF column in descending order

Observe the result, compare the two methods if you want, and prepare your complementary questions to the stakeholders in order to refine if necessary

5) Workshop review and adjustment of priorities with the stakeholders

Here is the critical time: Explain to one or several stakeholders why this or that need is not in priority 1, because it costs a little too much to achieve: You may be able to get away with a good beer

Show the results by projecting the Excel Sheet on your favorite video projector, the result of the prioritization

Comment, explain

If necessary, go back to the problematic Backlog items, and do not hesitate to cut them into pieces, in order to build first what has more value for the users

Do not forget non-functional requirements (NFRs) including service level requirements:

Service level requirements represent the qualities of the product. These qualities answer questions about security, capacity, availability (etc …) for your product

You will find a list of the main questions of this type in the tab “Non functional requirements”

Conduct a specific workshop on these issues with the business, other stakeholders, your team’s people, a representative of the Enterprise Architecture, an Ops or DevOps representative, a representative of the application architecture

Give a value to each topic as previously, for the tab “Functional requirements”

Too many workshops?

I would say no: Each workshop is an opportunity to inspect your Backlog items with a different cast and a different perspective

When I run these different workshops, naturally the Backlog items are reformulated, sometimes corrected, cut into pieces if they contain several ideas (Story Splitting), or simply deleted

We win on all the desks, and all teams and stakeholders have the same vision of what will be built, in what order, and for when (roughly, + – 20%)

Customization of the tool:

During the various workshops seen above, it is important for stakeholders to feel comfortable answering the questions you present to them.

Depending on the type of product evaluated, the answers presented in the various Dropdowns may be more or less relevant

Do not hesitate to modify the text in the tab “Parameters” that you can then hide. Be careful, however, not to delete the numbers: 1., 2., 3., 5., 8. (as they are used in formulas)

If you are adding columns for more questions to define the value (Pains, Business Profit in addition to Persona Benefit), consider expanding the size of the matrix, as the calculation value will be higher


Now you just have to copy each of the prioritized lines in your favorite Agile repository (JIRA, Agile Manager, Trello …)

Add new lines:

Click-right on a table cell, then


Copy columns 7 to 16 for the lines inserted in the tab “Functional requirements”

Copy columns 4 to 13 for the lines inserted in the “Non-functional requirements” tab

Columns description:
Subject / Use Case Classify your needs by use case (which itself refers to a business activity). You can also, for example, replace this column with two columns: Process and Activity, if you want to stick more to a business process
Persona Main user archetype for whom the Backlog Item is done
ID It is often convenient, during a workshop, to be able to refer to a unique and sequential identifier of the discussed requirement
Backlog Item description Short description of the Backlog Item (As … or Feature Driven Development (FDD))
Expected benefit Optional: To facilitate a more objective determination of the business value of the Backlog item
Target Product Optional: In the case of a multi-product project, which product will carry mostly of the requirement
Benefit Business benefit for the end user (Dropdown list)
Prejudice Risk not to do (Dropdown list)
Manufacturing risk Manufacturing risk (Dropdown list)
Value Business value : Benefit + prejudice
Risk Manufacturing risk (As a reminder)
Priority Calculation of the priority according to the Value / Risk matrix (“Risk Matrix” tab): to use as an ascending sorting column
Points Number of points determined by the Scrum Team, Squad Feature Team, Pizza Team, … (Dropdown list)
Time criticality How does the user/business value decay over time? Is there a fixed deadline? Will they wait for us or move to another solution? Are there Milestones on the critical path impacted by this? (SAFe concept)
Risk reduction What else does this do for our business? Does it reduce the risk of this or a future delivery? Is there value in the information we will receive? Will this feature open up new business opportunities? (SAFe concept)
WSJF WSJF calculation: (SAFe concept) : (Benefit + Time criticality + Risk reduction) / Points: to use as an descending sorting column
M*D Estimate in Men * Days at this stage (It’s up to you to write your magic formula, valid at + – 30%, for example: Points * constant)
Comments Comment, assumptions, … what type of solution the stakeholders wish, …