Short answer
Say what the problem is, who has it, and what done looks like. Add one example and anything that’s out of scope. A request a developer can start without asking a question ships days faster than one that needs a conversation first.
Why does request quality matter so much?
Every unclear request starts with a round of questions. Each round trip costs a day if people are busy. Clear requests skip that, so the same queue ships noticeably more.
The template
Problem: what’s going wrong or missing, in one or two sentences.
Who: which users hit it, and how often.
Done looks like: how you’ll know it works, written as things you’ll check.
Example: a screenshot, a link, a real record or a sketch.
Not this time: anything tempting that should wait.
A worked example
Weak: “Reports need exporting.”
Strong: “Problem: account managers copy the monthly usage report into Excel by hand every month, which takes about an hour each. Who: the four account managers. Done looks like: a Download CSV button on the usage report, exporting exactly the columns on screen, respecting the current filters, with dates in DD/MM/YYYY. Example: screenshot attached. Not this time: scheduled email exports.”
The second takes two minutes longer to write and saves a day of back-and-forth.
Describe the problem, not the solution
“Add a dropdown here” might be the right answer. It might also be that a dropdown is the third-best option and a default value would solve it outright. Describing the problem lets the team bring judgment to it. That’s a large part of what you’re paying for.
Keep requests small enough to ship
If a request has “and” in it three times, it’s probably three requests. Smaller requests ship sooner, get reviewed faster and are easier to roll back if something’s wrong.
Bug reports: the four things that matter
- What you did, step by step.
- What you expected.
- What happened instead, with a screenshot or error message.
- Where: which browser or device, which account, roughly when.
If it’s breaking production for users right now, say so in the title. Urgent production bugs jump the queue.
Questions
Do requests have to be technical?
No. Plain English is best. The team turns it into the technical plan; your job is to describe the problem and what done looks like.
What if I’m not sure what I want?
Say so, and describe the problem. Working out the right solution is part of the job, and on Embedded Plus the monthly planning session is a good place for the bigger questions.