Good tickets will save you a ton of time and therefore a ton of money! Whether you're a nimble startup needing a consultant who can guide you through the complex IT-Jungle or a large-scale international company.
And yet - I see bad tickets every single day. Tickets that require three follow-up messages before a developer can even start. Tickets bouncing back and forth between stakeholder and dev for days. Tickets so vague that three developers would come up with three completely different solutions.
Let's fix that.
What makes a bad ticket?
Before we talk about good tickets, here's what a bad one looks like:
"The login is broken. Please fix it."
That's it. That's the whole ticket. Where is the login broken? In what browser? For which users? Since when? What does "broken" mean - does the button not respond, does the user get an error, or does the page just redirect somewhere wrong?
A developer reading this has two options: guess, or ask. Both waste time. One of them ships the wrong solution.
The anatomy of a good ticket
1. A clear, specific title
The title should tell you what needs to happen without even opening the ticket. Compare:
- Bad: "Fix login"
- Good: "Login button on iOS 16 (Safari) does not respond to tap"
A good title is specific enough that you could search for it six months later and immediately know what it was about.
2. Description: the What, not the How
Describe the problem or requirement - not the solution. Developers are paid to figure out the how. Your job is to explain the what clearly.
If it's a bug: describe what happens, what you expected to happen, and the exact steps to reproduce it. If it's a feature: describe what the user should be able to do, from the user's perspective.
A screenshot is worth a thousand words. A screen recording is worth a thousand screenshots. Always attach visual proof when reporting a bug - it cuts debugging time in half.
3. Acceptance Criteria
This is the most underrated part of any ticket. Acceptance criteria answer one simple question: how do we know this is done?
Without them, "done" means something different to the developer, the QA tester, and the stakeholder. With them, everyone is on the same page from day one. Write them as a simple checklist:
- User can log in with email and password
- Failed login attempts show a clear error message
- After 5 failed attempts, the account is temporarily locked
- Works on Chrome, Firefox, and Safari (desktop and mobile)
A ticket without acceptance criteria is like ordering a pizza without specifying the toppings. You'll get something - just probably not what you wanted.
4. Priority and Context
Not every ticket is a five-alarm fire. Tell the developer whether this needs to ship today or can wait until the next sprint. And explain why it matters - what's the business impact? This context helps developers make smarter decisions when they hit unexpected edge cases mid-implementation.
5. Technical details (if you have them)
If you know which system, endpoint, component, or page is affected - say so. Don't make the developer play archaeologist. Got relevant logs, error messages, or network requests from the browser console? Attach them. The more context, the faster the fix.
The golden rule
Before you submit a ticket, ask yourself: could a developer start working on this right now without asking me a single question?
If the answer is no, the ticket isn't ready yet.
The cost of a bad ticket isn't just the back-and-forth messages. It's the context switching, the wrong implementation, the re-work, the missed deadline. Write it right the first time.
Writing a good ticket is an act of respect for the developer's time. The 10 minutes you invest in writing a proper ticket saves hours of communication - and prevents the wrong thing from being built entirely.