The short version
- Ten requests, worst to best, on the same board.
- A good heading names one difficulty. Read it back and ask if two people would build the same thing.
- A request isn't a user story, and converting one costs you three things.
- Keep the card, write the stories under it, and close the card rather than the stories.
The feature request examples below are cards, not the messages that produced them.
Somebody has already told you something, you've already decided it's a request, not a defect, and now you've to write it down in a form that will still make sense in four months when it has thirty votes on it.
That writing down is where most boards quietly go wrong, and it's invisible while it's happening. A badly written card doesn't look broken. It looks fine, it collects votes, and then one day you sort by votes and can't work out what the top row is asking for.
Every example below is written for this post. None of them is a real customer's card, because publishing what identifiable people wrote is their decision, not ours.
What does a rankable feature request look like?
A heading naming one difficulty, and a description saying when it happens and what the person does instead today.
Heading. Filter the request list by the person who submitted it.
Description. With more than about two hundred requests, finding the ones a particular customer raised means scrolling and reading. This comes up whenever we prepare for a renewal call and want to see what that account has asked for. Today we export the whole list and filter in a spreadsheet, which takes about twenty minutes each time.
That's the whole thing, two fields and no form, and what happens to a request after it's typed is the rest of its life.
The last part is the one everybody leaves out and it's the most valuable, because a workaround is evidence. Somebody who exports and filters every month has proved the problem is worth twenty minutes to them. Somebody who has no workaround has usually not hit the problem yet.
There's a board doing this already if you want to look at one, and the demo is open without an account.
Want a board rather than a list? Seven idea management tools, what each bills on and what it costs.
Ten examples, ranked worst to best
Same board, ten headings, in the order of how much you can do with them.
| Heading on the card | Verdict |
|---|---|
| Improve the dashboard | Unrankable. Nobody, including the author in a month, knows what would satisfy it |
| Make it faster | Unrankable as written. There is a real complaint under it and it needs one question to surface |
| Mobile support | Ambiguous. Could mean a responsive layout, a native app, or one screen working on a phone. Three different quarters of work |
| Add chat integration | Too broad. Notifications into a channel and a slash command that creates a request are unrelated pieces of work |
| Dark mode | Fine, because the phrase is unambiguous in this industry. One of the few short headings that survives |
| Export the board as a CSV | Good. A named output in a named format |
| Filter the request list by submitter | Good. One list, one filter, one field |
| Let me reply to a comment without opening the card | Good, and specific enough to estimate |
| Warn me before I merge two cards with different owners | Very good. Names the exact moment and the exact risk |
| Stop the weekly digest counting cards I already read | The best of these. Names a behaviour, names the wrong outcome, and implies the test |
The pattern down that list isn't length. It's whether the sentence contains a verb that somebody could be observed doing.
What is the test for a good heading?
Read it back and ask whether two people would build the same thing.
That's the whole test and it takes four seconds. Improve the dashboard fails immediately. Export the board as a CSV passes. Mobile support fails, which surprises people, because it feels concrete and it's not.
A second test, for the cards that pass the first one, is whether you could tell somebody it was done and have them agree. Dark mode passes both. Make it faster passes neither, because faster than what's a question nobody wrote down.
Neither test is about how much you like the idea. A terrible idea can be perfectly rankable and a wonderful one can be unwritable, and keeping those two judgements apart is most of the discipline.
How is a feature request different from a bug?
A request asks for something that never existed. A bug reports something that exists and is behaving wrongly.
The reason it matters here's that the two don't get ranked the same way. Whether to fix a defect isn't a popularity contest, and a bug sitting on a voting board waiting to be popular enough is a decision nobody meant to make.
The full version of that argument is here, including the cases where it genuinely isn't obvious.
For writing purposes the difference is simpler than the philosophy. A bug card should contain what you did, what happened and what you expected.
A request card should contain the difficulty, when it happens and what you do instead today. Different fields, so putting them in the same box produces a card that's half of each.
Is a feature request the same as a user story?
No, and the difference costs you something every time you convert one.
A user story is a development artefact. It's written for the team building the thing and it usually takes the form of somebody wanting something in order to achieve something. It's deliberately small, it belongs to a sprint, and it exists to be estimated and closed.
A feature request is a customer artefact. It's written by, or on behalf of, a person outside your team, it's not sized to anything, and it exists to be counted alongside other requests so you can see which difficulty is most common.
The two live at different stages and both are useful. The mistake is treating the conversion as a rename.
What does a request lose when it becomes a user story?
Three things, and you can lose all three without noticing.
It loses the count. A request carrying thirty votes becomes a story carrying none, because votes don't survive the move into a development tracker. If the story is then split into four stories, the thirty is spread over nothing at all and the evidence for doing the work has evaporated at exactly the moment somebody asks why it's being prioritised.
It loses the requester. A story says a user wants. The card it came from knew which users, and once that's gone you can't tell the person it shipped, and you can't tell whether the thirty votes came from thirty free accounts or from your three largest customers.
It loses the failure. A request usually describes what the person does instead today. Stories rarely carry that, because it's not needed to build the thing, and it's exactly what you need six months later when somebody asks whether it worked.
The practical answer isn't to stop writing stories. It's to keep the request as the durable record, link the stories to it, and let the request be the thing that closes when the work ships. Which is also the only arrangement in which the people who voted can be told it's done.
How do you convert one without the loss?
Keep the card, write the stories underneath it, and close the card, not the stories.
A worked pair, using the good example from earlier.
The request. Filter the request list by the person who submitted it. With more than two hundred requests, finding what one account asked for means exporting and filtering in a spreadsheet, roughly twenty minutes before every renewal call.
The stories. Add a submitter column to the request query. Add a filter control to the list header. Persist the selected filter across page loads.
Three stories, one request, and the request still holds the votes, the requester and the workaround. When the third story ships, the request closes, and the people whose votes are on it are the people who get told.
The failure mode is the opposite arrangement, where the request is closed as converted the moment the stories are created. The board then shows the work as finished while the customer has nothing, and the requester finds out either never or by accident.
What should the description actually contain?
Three sentences, and the third is the one worth insisting on.
What's difficult. When it happens. What you do instead today.
Everything else is optional and most of it's noise. A proposed solution is welcome and should be treated as a hint, not a specification, because a person who has designed an interface for you has usually been fighting something for a while and the design is their guess at a fix.
Screenshots help. Priority labels supplied by the requester help nobody, because everything is urgent to the person writing it.
If you want the fields written out as an actual file to hand to people, there's a template on this site in plain markdown and as a GitHub issue form.
How many examples does a board need before ranking means anything?
More than you have, at first, and that's fine.
A board with nine cards on it doesn't need ranking. You can hold nine things in your head and the sort order is decoration. The point at which counting starts to earn its keep is somewhere past the number you can read in one sitting, and for most people that's a few dozen.
What matters more than the count is the spread. Forty cards that all came from the same two customers tell you about two customers. Forty from thirty different accounts is the beginning of a signal, and the reason a vote count is a better relative measure than an absolute one is exactly this.
14 days, a card at signup, then $9 or $39 a month.