Is WSJF "better" than traditional ROI calculations for Applications?

I love road trips, and i like analogy.  

The Premise: Two couples are planning a road trip.

The "Perfection" group: This group spends a year planning a single, perfect itinerary. They book every hotel, museum, and restaurant reservation months in advance. They have a massive, inflexible budget and a 50-page binder and a fixed budget line item for everything. If a restaurant is closed or a friend gets sick, the entire plan and budget is at risk. It's an all or nothing roadtrip. Everyone's holding their breath and each part of the plan feels risky.

The "Flow" Group: This group has a general idea of their destination (Philadelphia). They decide to drive for a few hours (Planning interval) and then check in with each other (PI Event). "Where do we want to go next?" they ask (Retrospective, Feedback). They agree to stop at the most interesting thing that's coming up soon (Weighted Shortest Job First). They choose what needs upfront planning, such as booking an event outing but not everything. They have a modest amount of cash on hand (their lean budget) and use apps like Airbnb or Yelp to find local spots (leverage suppliers). They let the person in the passenger seat make decisions on what music to play or where to eat next (empower local decision making). All of this feels balanced, and the group is in flow with flexibility.

I signed the Agile Manifesto in 2012. Since then I have selectively applied various lean, and agile principles, tools and techniques to software development processes. One key question that often comes up is "How do you measure ROI for applications" - this is a key question often overlooked. However, the economic benefits are an essential driver for investment decisions in technology

I have trained and certified in SAFe. It is essential for a team embarking on SAFe go through training across all levels in the organization. Epics and participated in prioritization of enablers and functional epics across a portfolio with leadership teams. The goal is to maximize economic benefit.  A pre-requisite to that is the way in which prioritization is done and what it's measured against.

Traditional Return on Investments consider "green or white dollars", where as SAFe prioritized "flow". WSFJ isn't an ROI methodology however I argue it is apt for many situations in IT investment choices.

Taking an Economic View in Practice

- Deliver Early and Often: This is valuable to ensure flow

- Operate within Lean Budget: Fund teams, this is akin to spending mostly "white dollars" - the staff.

- Understand Econonic Tradeoffs for Solutions: This is where a common consensus on Value needs to be defined first.

- Leverage Suppliers: Buy versus Build can significantly increase speed to market as well as ROI

- Sequence Jobs for Maximum Benefit: Weighted Shortest Job First is the way to sequence almost anything at any scale

- Empower Local Decision Making - ensure that the value determination is local to a group - perhaps product management team, and the duration is local to the development team estimation. 

Cost of Delay is an interesting way of determining Value and it's essential to bring everyone on board to the determination of Value. It's a post-mortem view of what happens if we don't so this? Thanks to Donald Reinertsen CoD is a priority.

CoD = BV+TC+RR | OE

BV is Business Value e.g. reduction in operating costs, or increase in revenue

TC is Time Criticality - e.g. regulations, reputational harm

RR is Risk Reduction e.g. Security risk via SSO

Opportunity Enablement e.g. Enabler epics

CoD / Size is used in SAFe. 

"Those who do the work size the work" Steve Adolph has a good video on his.

Basically, WSJF delivers the low hanging fruit without impact to the most important things business wants by much. You get some value really quickly, versus nothing for a very long time.

Conclusion

ROI calculations almost always depend on the agreed-upon "Value" score. This is where almost all 'returns' on application value falter. This is a highly subjective, non-scientific area and there is no standard methodology that has been universally and easiliy adopted. The value is contextual and each leadership team must define what and how they can generally align on value by assigning metrics to it. 

Cost of Delay is a great way to define Value for software and technology delivery for applications. 

C4 should be the de-facto diagramming style for SAFe Agile Teams

Intro

Let me first start with how I wrote this, because it's important. In my career I have crafted several architectural decisions. The most challenging presentations are when I have had to address both technical and business audiences. Technical story telling is an essential skill. As the Senior Director of IT Strategy and Architecture, I applied the "Pyramid Principle" extensively. You start with the answer, then state the why, how, and next steps. Usually, presenters don't do this. Instead they "build up" to the answer. Meanwhile, their audience has "lost the plot". Ever since I adapted this communication style, effectiveness of my communication has been lauded.

The Answer

Pilot C4 Diagramming Standard for the next PI (Planning Increment).

To deliver software that is timely, high-quality, and aligned with business goals, you should adopt the C4 diagramming style as the standard for visualizing architecture. C4 provides a clear, layered way to represent systems that works for executives, architects, and developers alike.

The Why

Executive Perspective

(a) Shared Understanding Across Audiences

C4 diagrams scale from high-level context (business view) to technical detail (developer view), ensuring everyone. From stakeholders to engineers everyone can interpret the architecture without the need for heavy tooling. Just enough design facilitates acceleration of the solution.

(b) Agility with Discipline

Unlike heavyweight modeling approaches, C4 is lightweight and iterative, making it compatible with agile teams while still ensuring design intent is explicit.

(c) Risk Mitigation 

Consistent visual models surface integration, security, and scalability risks early, reducing costly redesigns.

Practitioner Perspective

(a) Clarity of Scope and Boundaries

Context and container diagrams make dependencies, APIs, and infrastructure responsibilities unambiguous.

(b) Scalability and Deployment Readiness

Component and container views map directly to runtime environments, cloud services, and CI/CD pipelines.

(c) Knowledge Retention

C4 diagrams are simple enough to maintain as living documentation, reducing reliance on tribal knowledge.

The How

Like Google Maps, C4 lets you zoom in and out: executives see the “city map” (context), architects see the “neighborhood layout” (containers), and developers see the “street-level details” (components and code).

Leading organizations and open-source communities use C4 to replace ad-hoc diagrams with a consistent, widely understood notation.

Practitioner Example:

1. Context Diagram: Shows how the system interacts with users and external systems.
2. 
   Container Diagram: Breaks down major applications, services, and databases.
3. Component Diagram: Details the internals of each container and key responsibilities.
4. Code Diagram: Optional, zooming into classes, libraries, or modules for critical areas.

Practically, Context and container diagrams should be developed and maintained. The component and code diagrams usually have diminished return on time investment.

Leading Indicators

Business Outcomes

• Reduced communication gaps between business and IT.
• Faster alignment on architectural decisions, accelerating time-to-market.
• Lower risk of rework by ensuring shared understanding upfront.

Technical Outcomes

• Consistent, lightweight architecture diagrams across teams.
• Easier onboarding for new developers and faster knowledge transfer.
• Clear alignment between architecture, infrastructure, and code.

Decision

• Decide to adopt C4 as the standard architecture visualization method across projects.
• Provide teams with starter templates and simple guidance.
• Pilot the C4 approach in the next project increment and review effectiveness with both stakeholders and developers.

Conclusion

You can steal this, customize it and use it for your company. Good luck!!