Weighted Shortest Job First is the right instinct: sequence work so the things whose delay costs the most, relative to their size, go first. I learned WSJF inside SAFe, which scores its components in relative, modified-Fibonacci points because dollar figures are rare; the economics underneath are Don Reinertsen’s (The Principles of Product Development Flow). When a client has believable, dollarised cost-of-delay numbers, I’ll sequence on them all day. Most portfolios I meet don’t have those numbers. Cost of delay exists for the two or three epics somebody fought about, is contested for a dozen more, and is guesswork past that. You can stall for a quarter trying to dollarise the whole list, or you can get a defensible forced-rank order out of the preferences the organisation already holds.

I’ve run the SAFe-style scoring version myself, coaching a prior client’s leadership, split between Europe and Oceania, through scoring value, time criticality, risk, and job size in Fibonacci points in a shared spreadsheet: eight hours of discussion over four days. One product leader had described the state before it as needing to address five large initiatives at once. The exercise landed (I suspect it gave the organisation its first formal Product Backlog, and one held with broad support), but eight hours of invented numbers is a heavy lift to repeat. Forced choice keeps the agreement and drops the arithmetic.

My primary mechanism for the second path is adaptive forced choice: paired comparisons, the preference-elicitation move conjoint studies in market research are built on. Put two epics on the screen, ask which one the organisation would rather have, and let many small, easy judgements assemble a ranking that no single big judgement could produce. Where a SAFe-style scoring session asks the room to agree that time criticality is an 8 rather than a 13, forced choice asks a smaller question—this epic or that one—and nobody has to invent a number. I run it through two channels at once. Stakeholders vote in the room, in Delphi rounds, with Plickers cards. Engineers work directly in Prioneer.io, the same engine that serves the room its comparisons.

The room

Prioneer drives the screen, serving one comparison at a time—”Epic F vs Epic R”—with four answers: A, strongly prefer left; B, moderately prefer left; C, moderately prefer right; D, strongly prefer right. Everyone holds up a Plickers card, a paper square whose rotation encodes the answer. Three properties make the cards better than raised hands or a polling app for this job. A neighbour can’t read a Plickers card at a glance, so the first vote lands before anyone can anchor on the boss’s arm. Nobody needs a phone or a laptop to vote—the only device in the room is mine—so people stay present instead of drifting into their screens. And I scan the whole room in a few seconds, so the tally is on the screen while the choice is still warm.

Then the Delphi move: where the room splits, we hear the strongest voice on each side and vote the same pair again. (Delphi is the RAND-developed technique of iterated judgement with controlled feedback; mine is a lighter, in-room version.) In my experience a second vote after two minutes of argument moves more minds than an hour of open discussion, because the argument has a decision to land on. Group preferences can cycle—a room may prefer F over P, P over R, and R over F—and I leave those to Prioneer, whose ranking model reconciles the full answer set rather than trusting any single chain of inference.

The engineers

Engineers skip the cards and make their trade-offs straight in Prioneer, whose pairwise ranking is adaptive: once it knows F beats P and P beats R, transitivity means it stops asking about F and R, so nobody grinds through every possible pair. They rank the same epics on complexity, uncertainty, and effort: the denominator side of the WSJF ratio, judged by the people who’ll carry the work.

What comes out

A full forced-rank order of the portfolio, and, more usefully, the disagreements. Where the stakeholder ranking and the engineering ranking part company, you’re looking at WSJF’s numerator and denominator arguing with each other, and that argument is the agenda for the next working session.

A perfect ordering was never the goal; what you need is enough stakeholder alignment to limit work in progress. Swapping two adjacent epics in rank costs little. Running twelve at once costs a context-switching tax on all twelve. Larman and Vodde call that the Context-Switching Vampire, fed by well-intended, perfectly reasonable requests from every direction, and their structural cure in LeSS is a single source of work for the teams. The forced-choice pass buys the alignment that makes a single source survivable: once the room has watched the order assemble out of its own votes, the organisation can leave the tail of the list unstarted without relitigating it every week.

At one client, a public B2B SaaS company, I ran this with 30+ stakeholders including C-level leadership, and it reset the priorities of the entire epic portfolio (a reset no single executive could have driven alone). The final sequence was based heavily on the quantitative results, with the stakeholder-versus-engineering gaps taken to working sessions. The decisions were theirs; the mechanism made the preferences visible enough to decide on. Epic WIP fell and throughput rose.

When you do have the dollars

Use them. At another client I built deterministic cost-of-delay sequencing into the delivery tooling itself—Delivery Intelligence—with P50–P95 probabilistic forecasts; the published case study includes a modelled example valuing one epic’s 2.5-week acceleration at about $1.25M in avoided cost of delay. The forced-choice pass gets a portfolio moving while the data matures, and it builds the shared preference structure that makes the later dollar arguments tractable.