Feature request prioritisation on this board is scoring with three numbers, and every request carries all three. Demand, which is computed from what people did.
Effort, which is the one thing you type. And priority, which is demand divided by effort. Reading those three from your own application is documented with the fields they come back in.
That is the whole system, and the reason to write the formula out on a public page is that a prioritisation score you do not understand is a score you will not trust on the morning you need it.
How is the demand score calculated?
Votes times three, plus comments times two, plus views times a tenth.
demand = (votes × 3) + (comments × 2) + (views × 0.1)
The weights are deliberate and they are worth arguing with. A vote costs a click, a comment costs a paragraph, and a view costs nothing at all, so they are counted in that order.
Views are in the formula because a request nobody votes for but four hundred people opened is telling you something, and they are divided by ten because the thing it is telling you is weak.
That is the behaviour as it ships, and a trial runs 14 days with a card at signup if you would rather confirm it than read it.
The number is not normalised, capped or decayed. A request with a thousand views and no votes scores a hundred, and so does a request with thirty three votes and one comment. That is the arithmetic doing what it says rather than a judgement being smuggled into a constant.
What is the effort estimate?
Five sizes, and it is the only input on this page that comes out of your head rather than out of the board.
| Badge | Value | What it means |
|---|---|---|
| XS | 1 | hours |
| S | 2 | days |
| M | 3 | a week |
| L | 4 | weeks |
| XL | 5 | a month or more |
Five buckets rather than a number of days, because the difference between an eight day estimate and an eleven day estimate is noise, and a scale with more resolution than your estimates have is a scale that invites arguments about the wrong thing.
A request with no effort set has a priority of zero and sorts to the bottom of a priority ordering. That is intentional. Something nobody has sized is not something you have decided about.
What is the priority number?
Demand divided by effort, rounded.
priority = demand ÷ effort
That single division is what makes the board useful, because it is the only number on it that can put a small request above a popular one.
A request with a demand of 89 and an XL effort scores 18. A request with a demand of 72 and an S effort scores 36. The second one is half as wanted and twice as worth doing this week.
Sorting a board by priority takes one dropdown, and it is the single most useful view on the product for the half hour where a team decides what the next fortnight looks like.
Can the demand score use weighted votes?
Yes, and it is a switch rather than the default.
By default the votes term is the plain headcount. There is a setting that swaps it for the weighted total, so that a vote from a customer on a tier with a multiplier feeds the demand score at its weight instead of at one. The switch is on the same panel as weighted voting itself.
Leaving it off is the honest default, because it keeps the two ideas apart. Demand then answers how many people asked, and the weighted count beside it answers who they were, and you can read both without one having quietly eaten the other.
Why does the order keep changing?
Because two of the three inputs move on their own.
Votes and comments arrive while you sleep and views accumulate every time somebody opens a request. Only effort sits still. A board sorted by priority on Monday and again on Friday is a different board, and that is correct behaviour rather than instability.
What it means in practice is that the ordering is a reading rather than a decision. The number is there to start the conversation in a defensible place, not to end it.
Where this stops
Four places, and they are worth knowing before you lean on the number.
It cannot see anything you did not tell it. Strategy, a contractual commitment, a dependency on work that has not started, the thing your largest customer mentioned on a call. None of that is in the formula, and none of it should be, because the moment a score includes a judgement it stops being checkable.
It is only as good as the effort column. Demand is measured, effort is guessed, and the division mixes the two. A team that sizes everything M gets a priority ordering that is just the demand ordering.
It does not decay. A request from two years ago with four hundred accumulated views scores on those views forever. There is no half life and no recency term.
It says nothing about revenue on its own. The demand score counts people. Money arrives only if you turn weighted votes on, or if you read the weighted total beside the plain one.
What this costs
All three numbers are on every plan. They are not a Pro feature and there is no upgrade behind the formula.
The trial runs 14 days and a card is required to start it, then it is $9 a month for Lite and $39 for Pro, or $90 and $390 a year.
The honest summary
Demand is three numbers you did not have to collect, weighted in the order of what they cost the person who produced them. Effort is the one thing you supply. Priority is the division, and the division is the only part that can tell you something the vote count could not.
If you want the arithmetic to include money, weighting is the page for that. If you want the definitions rather than the implementation, the prioritisation framework page compares five of them over one dataset.
14 days, a card at signup, then $9 or $39 a month.