Prioritization (WSJF)

WSJF stands for Weighted Shortest Job First. The idea behind it is simple and uncomfortable: while a request waits, it costs something (revenue not billed, an unhappy customer, a risk that stays open). That cost is called the cost of delay.

If two requests have the same cost of delay, do the cheaper one first — it releases the same value sooner. That, and only that, is what the calculation does.

The real gain is not in the number: it is in comparing a support request with a project request on the same scale, instead of letting priority belong to whoever shouted loudest in the meeting.

WSJF is "cost of delay divided by size": whatever loses the most value by waiting goes first, corrected by effort. You enter business value, time criticality, risk reduction and size — and the calculation comes out ready, with the breakdown visible. It serves to answer "why THIS before that?" without a debate of opinions.

Here you give the WSJF priority score of a request: three value scores (business value, urgency and risk/door it opens), the estimated effort and the justification in text. The score is calculated from them and it is what orders the scored backlog — from highest to lowest.

WSJF weighs four numbers: business value (how much this is worth once it is done), urgency (the cost of waiting — what is lost each week it sits idle), risk/door it opens (what it unlocks or protects) and effort, which enters as the divisor. The score grows with the first three scores and FALLS with effort: valuable and cheap delivery rises, valuable and expensive delivery drops to later. The justification is the most-read field afterwards: write the reason for the scores so that the prioritization survives the meeting in which it was made.

score = (value + urgency + risk reduction) ÷ effort

Business value — how much the company gains (or stops losing) once this exists.
Time criticality — how much the value shrinks if it takes longer. A tax-closing feature delivered after the deadline is worth almost nothing; the same one delivered before is worth everything. This is NOT "the urgency of whoever asked".
Risk reduction — how much this brings down a risk or opens the way for other things. This is where the technical debt nobody prioritizes comes in.
Effort — the size of the work.

All on the same 1 to 10 scale (it is not Fibonacci). Each score carries the justification of whoever gave it — a score without an argument is the one nobody can defend the following week.

It is calculated on saving and is read-only. If the result could be edited by hand, the calculation would become decoration for the usual opinion — which is exactly what the method exists to avoid.

The score starts neutral (5 on everything). This is intentional: whoever prioritizes has to take a stand, and moving away from 5 is the decision. The possible score ranges from 0.300 (everything low, maximum effort) to 30.000 (everything high, minimum effort).

One score per request: if one already exists, edit the existing one instead of creating a second. The list already is the prioritized backlog — it comes out sorted from highest to lowest score.

In the three numerator fields — value, urgency and risk — a blank score is treated as 1, the floor of the scale: this is conservative, the request goes down.

In effort there is no floor, because it is the divisor: assuming 1 would give the most favorable divisor there is precisely to what nobody sized, and the least filled-in request would lead the backlog. So, without effort, there is no score. The request is saved normally, appears at the end of the list marked "no score" and is left out of the radiator's "next by the numbers" block — an item that didn't enter the calculation cannot be presented as its result.

It is the honest behavior: the system doesn't make up a size in place of whoever prioritizes. For the request to enter the queue, size the effort from 1 to 10.

When you save a view with the Views button, it stores four things: the search text, the applied filters, which columns appear (and in what order) and which column the list is sorted by. Applying the view restores everything at once — including resetting the sort and the page you were on, so the result is exactly what the view describes. Views saved before this version remain valid: whatever they didn't store simply doesn't change when applied.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

A blank effort does NOT become 1: without a declared size, the request has no score and goes to the END of the list, marked as "no score" — instead of rising to the top with an invented divisor. The screen warns you when this happens. It is a deliberate choice: the system does not guess a size on behalf of whoever prioritizes, because an "ultra-urgent" request with unknown effort ranked at the top would be a comfortable lie. Size the effort (1 to 10) for the request to truly enter the queue.

In the record's activity panel, each note has "Turn into request". The click creates a ticket with the note's text, who wrote it and the link to this record — nothing is retyped. Use it when the note is a request for action ("someone needs to review this"); the note stays where it was. The button only appears once the record has been saved; a read-only session (demo) doesn't create one.

No. It produces a suggested order and nothing is written back to the request — the board still belongs to the team. The number's role is to reverse the burden of the conversation: instead of justifying why a request should go up, now you have to justify why it should jump the queue.

When the team disagrees with the order, the useful discussion is almost always about a specific score ("urgency 9? why?") — and that is where the method pays for itself.

No, and it's better not to. Score what is being considered for the coming weeks. The radiator shows how many open requests have no score — that number is the measure of the "blind backlog", and it serves as a reminder, not as a target to bring down to zero.

Open the record and look at the Timeline on the right: it shows each change as "from one value to another", with the person and the date. When there are many changes, use the two filters at the top of the timeline — one by field, the other by person. The search runs in the database, so old changes show up just the same. You can also ask Tenkai: "who changed contract 482?".