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 scrum.org).
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.
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:
THIS TOOL COMBINES TWO VALORIZATION METHODS:
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.
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,
– 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.
THE NEEDED WORKSHOPS TO VALUE THE business needs:
Five workshops are needed because the cast is different for each of them
1) VALORISATION WORKSHOP WITH THE BUSINESS
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)
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
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
|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
|Main user archetype for whom the Backlog Item is done
|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))
|Optional: To facilitate a more objective determination of the business value of the Backlog item
|Optional: In the case of a multi-product project, which product will carry mostly of the requirement
|Business benefit for the end user (Dropdown list)
|Risk not to do (Dropdown list)
|Manufacturing risk (Dropdown list)
|Business value : Benefit + prejudice
|Manufacturing risk (As a reminder)
|Calculation of the priority according to the Value / Risk matrix (“Risk Matrix” tab): to use as an ascending sorting column
|Number of points determined by the Scrum Team, Squad Feature Team, Pizza Team, … (Dropdown list)
|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)
|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 calculation: (SAFe concept) : (Benefit + Time criticality + Risk reduction) / Points: to use as an descending sorting column
|Estimate in Men * Days at this stage (It’s up to you to write your magic formula, valid at + – 30%, for example: Points * constant)
|Comment, assumptions, … what type of solution the stakeholders wish, …