Rally Software

 View Only

Expand all | Collapse all

Calculating value - WSJF

  • 1.  Calculating value - WSJF

    Posted Nov 24, 2025 11:27 AM

    How is the Weighted Shortest Job First (WSFJ) score automatically calculated?  My understanding is that the calculation uses Value, RR/OE, Time Criticality, and Job Size.   (Business Value + Time Criticality + RR/OE) / Job Size

    I have the following fields defined (all system defined, no custome fields):

    • WSJF Score (decimal) 
    •  Value (integer)
      • Value Score
      • User/Business Value
    • RR/OE (integer)
    • Time Criticality (integer)
    • Job Size (integer)
      • Job Size this is just an integer, does not automatically pull from plan estimate or preliminary estimated value
      • Plan Estimate
      • Preliminary Estimated Value

    I have a Portfolio Item view that show all of the above fields but i have to calculate WSJF manually to have it display anything.



    ------------------------------
    Paul Gummo
    ------------------------------


  • 2.  RE: Calculating value - WSJF

    Posted Nov 25, 2025 09:02 AM

    Sounds like a great opportunity to build a custom page in Cursor AI that pulls in all of those portfolio items via API calls and then displays the values and calculates the WSJF score.

    -------------------------------------------



  • 3.  RE: Calculating value - WSJF

    Posted Nov 26, 2025 12:21 PM

    Thanks Mitch!

    An interesting idea for sure. But, for maintainability, I'm trying to stay away from Custom Code.  

    -------------------------------------------



  • 4.  RE: Calculating value - WSJF

    Posted Nov 26, 2025 09:07 AM

    There is an app in the App Catalog called WSJF Grid.  If you put that app on a custom page and make changes to the four fields within that app it will calculate the score and populate the WSJF field.  That field is not populated outside of this app as far as I know.  I don't know if they plan to build a version of the app for Custom Views, so it may only work until October 2026 when they plan to deprecate custom pages.



    ------------------------------
    Terry Ginzburg
    ------------------------------



  • 5.  RE: Calculating value - WSJF

    Posted Nov 26, 2025 12:18 PM

    Thanks for the WSJF Grid suggestion. 

    A great option! Except, as you mentioned, it will be deprecated in October.

    Now if only this functionality was added to the Custom Views (hint hint)

    -------------------------------------------



  • 6.  RE: Calculating value - WSJF

    Posted Jan 08, 2026 12:46 PM

    Hey Paul,

    Like Terry says, there's a chance that an official WSJF widget is somewhere in Broadcom's backlog.

    But in the meantime, I threw together a very bare-bones version of a WSJF grid that works as a custom app as well as a custom HTML widget within a custom view.

    At the moment it merely auto calculates and updates the WSJF score field based upon updates to the standard WSJF fields (RR/OE Value, User/Business Value, Time Criticality and Job Size). 

    Perhaps that's all that you were looking for?

    You can find the code here, within the rally_wsjf_widget.txt file: https://github.com/am283721/rally-wsjf-widget

    Andrew McGrath

    -------------------------------------------



  • 7.  RE: Calculating value - WSJF

    Posted Jan 09, 2026 10:01 AM
    Thanks Andrew!

    Will definitely take a look at this for the short term.

    To be clear, Broadcom/Rally plans to deprecate Custom Pages in Q3'26, but Custom Apps will remain available after Oct '26. Correct?

    Paul


    ________________________________
    CONFIDENTIALITY NOTICE: This e-mail communication, including any attachments, is the property of Western Reserve Group and is for the sole use of Western Reserve Group and the individual(s) or entity(s) to which they are addressed. This message contains confidential information and is intended only for the individual(s) or entity(s) named. Please notify the sender immediately either by email or by telephone at 330-262-9060 if you have received this email by mistake, and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.





  • 8.  RE: Calculating value - WSJF

    Posted Jan 09, 2026 10:30 AM

    Custom apps are the apps that exist on Custom Pages. They're added to custom pages via the app catalog. So neither the pages nor the apps will be available after October 31st.

    Almost all, if not all apps you've used in the past utilize the Rally App SDK, which is also part of this deprecation. This is the main reason apps don't work as a widget on custom views (along with some other nuanced differences between apps and widgets).

    The code that I shared with you is compatible as a custom html app on a custom page as well as a custom html widget on a custom view because it doesn't use the Rally App SDK and it is also able to determine which type of page it is on and react accordingly. So this particular app/widget "hybrid" will continue to work properly on custom views after the deprecation of the SDK and apps and custom pages.

    It's a bit confusing with all of the different terminologies. I hope that helped clear things up. 

    There's some good information found within the deprecation notices, if you haven't read through that yet: Rally Deprecation Notices

    -------------------------------------------



  • 9.  RE: Calculating value - WSJF

    Posted Jan 09, 2026 04:15 PM

    thanks for the link to the Rally Deprecation Notices. I've seen some of those before, but not all.

    -------------------------------------------



  • 10.  RE: Calculating value - WSJF

    Posted Jan 09, 2026 10:32 AM
    Edited by Andrew McGrath Jan 09, 2026 10:32 AM

    [Duplicate post - deleted]



  • 11.  RE: Calculating value - WSJF

    Posted Jan 09, 2026 04:21 PM

    Andrew,

    First, thank you for the code. Definitely appreciated!

    Unfortunately, there's an issue: we do not use Drag and Drop Ranking; we still use Manual Ranking. Any quick fix to switch the HTML code to Manual Ranking? The page throws an error because it doesn't know what DragAndDropRank is.

    -------------------------------------------



  • 12.  RE: Calculating value - WSJF

    Posted Jan 09, 2026 04:31 PM

    Answered my own question. Replace DragAndDropRank with Rank.

    -------------------------------------------



  • 13.  RE: Calculating value - WSJF

    Posted Jan 12, 2026 05:25 PM

    In my company we would like to do the same thing - be able to automatically calculate the WSJF instead of doing the calculation offline and manually entering it in Rally

    -------------------------------------------



  • 14.  RE: Calculating value - WSJF

    Posted Jan 14, 2026 03:35 PM

    Works like a charm!

    Create a Custom View, add the HTML Widget and paste in the code from above.

    -------------------------------------------



  • 15.  RE: Calculating value - WSJF

    Posted Jan 14, 2026 03:43 PM

    Andrew, thanks so much for your help on this!  I do have another question for you on prioritizing production fixes. WSJF works well at the Portfolio level, but how do you prioritize Defects as well? For example, in the next release, I want to implement a new Feature and fix the highest value defects.  Do you have a strategy for showing both on a single backlog while maintaining the objectivity of something like WSJF?

    -------------------------------------------



  • 16.  RE: Calculating value - WSJF

    Posted Jan 15, 2026 09:29 AM

    I'm glad to hear it's helpful!

    Unfortunately I am by no means an expert in SAFe best practices, so maybe someone else could provide you with some better guidance. But I'll take a stab at it. To me, WSJF works well at the portfolio item level, but is far too much overhead when it comes to prioritizing work at the sprint level (i.e. stories and defects). I'm not sure how your team(s) organize your defects. Do you assign them to the stories where the work was done? Do you assign them directly to a Feature that acts as a bucket for all defects for the PI? I think the answer to this question might be necessary to really answer your question.

    However you're doing it, the idea is that the features that contain the new work and the features containing the defects to be fixed are all pulled into the next PI. For defects or other work that may be deemed "technical debt", perhaps it's helpful to allocate a capacity (e.g. 15% or 20%) of the teams total capacity to work on these things.

    The prioritization is then done during sprint planning.

    Then there are a few different mental models that could be applied here:

    • If you are using objectives: How does each piece of work get us closer to completing our objectives? Is it just a nice to have?
    • A mini WSJF: "Business Value + Risk". What work provides the greatest value with the lowest risk? You could use a simple 1-5 scale here
    • Cost of delay: What happens if the story or defect is delayed? Does it block other work? Then it should be a higher priority

    And for defects in particular, it can be helpful again to allocate a capacity per iteration for fixing defects. And when you're doing this, focus on the highest severity defects first. The "Environment", "Priority" and "Severity" fields can be very helpful here.

    That seemed long-winded and perhaps not exactly an answer to what you were asking. But maybe it was helpful in a way?

    -------------------------------------------



  • 17.  RE: Calculating value - WSJF

    Posted 26 days ago
    Andrew,

    Thanks for your insight. Let me address a couple of your questions below:

    While I have SAFe training (SPC), we are by no means an entirely SAFe shop.

    I'm exploring using WSJF to support Sprint Planning. From our backlog, we have a long list of enhancements and defects that are periodically prioritized by the business. Unfortunately, from one prioritization session to the next, we forget the exact reasons why something was prioritized the way it was. Using WSJF, we can at least document a feature's characteristics so that when we need to prioritize it against shiny new features, we can do so more efficiently. Being able to objectively assess the WSJF makes it much easier to see where a new feature fits into the overall backlog.

    During new development, we trace defects to Features. However, once in Production, we do not trace defects back to the original User Story or Feature. Perhaps, something to strive for. Also, something to strive for is to use the Priority and Severity more uniformly. High-priority defects are generally addressed quickly, so we don't need to prioritize them from Sprint to Sprint.

    Thanks again for your insight. Always interesting to see how other projects are managed.

    Paul


    [cid:image001.png@01DC8B9A.AD497850]


    ________________________________
    CONFIDENTIALITY NOTICE: This e-mail communication, including any attachments, is the property of Western Reserve Group and is for the sole use of Western Reserve Group and the individual(s) or entity(s) to which they are addressed. This message contains confidential information and is intended only for the individual(s) or entity(s) named. Please notify the sender immediately either by email or by telephone at 330-262-9060 if you have received this email by mistake, and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.