About Jexo.io 🏅 Atlassian Silver Marketplace Partners 👇🏻 We build Jira Cloud apps to contribute to the growth of the Atlassian community. 🚀 Take a look at the agile apps we've built to help teams improve how they plan, track and manage work in Jira: jexo.app/marketplace-atlassian
Thanks for the video, short and straight to the point. So if my understanding is correct, the higher WSJF is the more prioritized feature will be? Something like that?
Thank you for this wonderful presentation. Quick question: did you use random numbers to for the job size or Fibonacci series? because you go from 1 to 5 respectively for XS, S
Thanks for this, it is very useful! I struggle to understand the difference between time criticality and risk reduction. They both seem related to time and risk associated with delaying. Can you please clarify? Thanks.
Hi 👋 Glad, it was helpful! True, these factors are both related to (time) urgency, but they still have different angles to look at the issue: Time criticality - we look if there's a specific deadline. Can we lose customers if it isn't completed in a certain time? OR Are there peak shopping periods, dates when regulations will be in effect, or license or contract expiration? Risk reduction - takes into account tasks or items that might prevent a significant impact from occurring. Is there any negative impact if we delay? Eg. an infrastructure upgrade may prevent services from going offline during a surge in traffic, or fixing a security gap may prevent a security incident. Sorry for the delay in response. Does this clarify the two terms? jexo.io/blog/backlog-prioritization-techniques-the-wsjf-method/
Do you have documentation that describes how you evaluate each metric? I would be especially interested in what is the way to evaluate business value. If you have 10 plus Project Managers it is needed for consistency of prioritization inside of the organization.
Hi Lukas, Thanks for your question! Let us share some thoughts here: If you use Low, Medium, High labels for business value, you can specify what they mean. Eg. Low is up to 1000$ return, Medium up to 5000$ return and High anything above 5000$. You can do more complex definitions of these that can be a guidance for you when assigning business value. Another approach is to prioritize backlog with all project managers together with a tool like priority planning poker (see video - ruclips.net/video/lu0E_h56I_M/видео.html). Here you would get managers together to asses business value and see if there are any outliers. Over time, the team gets a shared understanding of what low, medium and high means the same way developers eventually get a shared understanding when assigning story points during sprint planning. Let us know if this clarifies things for you! And subscribe to Jexo channel for more videos like that 🙌
How come you have left out Opportunity Enablement? And how come you are not using the "traditional" Fibonacci numbers for estimates? Any good experience in going away from those, that you can share?
Hi Jesper, thanks for your comment and questions! There are many variations to prioritization frameworks you can do. Nothing is set in stone and you can do adjustments that will work for your team and organization. This video describes the basic WSJF calculation framework but if you prefer you can always expand and add additional metrics like for example "Opportunity enablement". The way you can go about it is to add an additional metric to the sum that defines the "Cost of delay" or you can use either "Opportunity enablement" or "Risk reduction". It's similar when it comes to the Estimated size metric. You can use the Fibonacci scale and estimate using numbers. To increase adoption and make estimating easier you can use labels instead and map numeric values to them. An example from the video is a T-shirt size estimation but you could also use labels like Low, Medium, High. If you would rather work with complexity you can add Easy, Medium, Hard. These are just a few examples of variations to WSJF we've seen to be used. In general, teams are more likely to successfully and easily adopt a prioritization framework if it's easier to use.
About Jexo.io
🏅 Atlassian Silver Marketplace Partners
👇🏻 We build Jira Cloud apps to contribute to the growth of the Atlassian community.
🚀 Take a look at the agile apps we've built to help teams improve how they plan, track and manage work in Jira: jexo.app/marketplace-atlassian
Thanks for the video, short and straight to the point. So if my understanding is correct, the higher WSJF is the more prioritized feature will be? Something like that?
Excellent video. Very helpful
perfect, I understood in an easy way. hanks
Glad it helped, Neamat ✨ Thanks for feedback!
Thank you for this wonderful presentation. Quick question: did you use random numbers to for the job size or Fibonacci series? because you go from 1 to 5 respectively for XS, S
Thanks for this, it is very useful! I struggle to understand the difference between time criticality and risk reduction. They both seem related to time and risk associated with delaying. Can you please clarify? Thanks.
Hi 👋 Glad, it was helpful!
True, these factors are both related to (time) urgency, but they still have different angles to look at the issue:
Time criticality - we look if there's a specific deadline.
Can we lose customers if it isn't completed in a certain time?
OR Are there peak shopping periods, dates when regulations will be in effect, or license or contract expiration?
Risk reduction - takes into account tasks or items that might prevent a significant impact from occurring.
Is there any negative impact if we delay?
Eg. an infrastructure upgrade may prevent services from going offline during a surge in traffic, or fixing a security gap may prevent a security incident.
Sorry for the delay in response. Does this clarify the two terms?
jexo.io/blog/backlog-prioritization-techniques-the-wsjf-method/
Do you have documentation that describes how you evaluate each metric? I would be especially interested in what is the way to evaluate business value.
If you have 10 plus Project Managers it is needed for consistency of prioritization inside of the organization.
Hi Lukas,
Thanks for your question!
Let us share some thoughts here:
If you use Low, Medium, High labels for business value, you can specify what they mean. Eg. Low is up to 1000$ return, Medium up to 5000$ return and High anything above 5000$. You can do more complex definitions of these that can be a guidance for you when assigning business value.
Another approach is to prioritize backlog with all project managers together with a tool like priority planning poker (see video - ruclips.net/video/lu0E_h56I_M/видео.html). Here you would get managers together to asses business value and see if there are any outliers. Over time, the team gets a shared understanding of what low, medium and high means the same way developers eventually get a shared understanding when assigning story points during sprint planning.
Let us know if this clarifies things for you! And subscribe to Jexo channel for more videos like that 🙌
How come you have left out Opportunity Enablement? And how come you are not using the "traditional" Fibonacci numbers for estimates? Any good experience in going away from those, that you can share?
Hi Jesper,
thanks for your comment and questions!
There are many variations to prioritization frameworks you can do. Nothing is set in stone and you can do adjustments that will work for your team and organization.
This video describes the basic WSJF calculation framework but if you prefer you can always expand and add additional metrics like for example "Opportunity enablement". The way you can go about it is to add an additional metric to the sum that defines the "Cost of delay" or you can use either "Opportunity enablement" or "Risk reduction".
It's similar when it comes to the Estimated size metric. You can use the Fibonacci scale and estimate using numbers. To increase adoption and make estimating easier you can use labels instead and map numeric values to them. An example from the video is a T-shirt size estimation but you could also use labels like Low, Medium, High. If you would rather work with complexity you can add Easy, Medium, Hard.
These are just a few examples of variations to WSJF we've seen to be used. In general, teams are more likely to successfully and easily adopt a prioritization framework if it's easier to use.