A Guide to Writing Good Tickets
I once joined a delivery team that was drowning. The squad of engineers, a designer, and a QA person (plus me, as the recently-joined PM) had a backlog a mile long, and although they were shipping code as quickly as they could write it, nothing seemed to land right. The backlog was a mile long, and as I looked through it, I couldn’t even begin to guess the value of anything in it. All of the tickets looked like “do this thing” and “do that thing.” The team was desperately trying to read the minds of the previous PM and their stakeholders, and they felt like they had no way to provide input in what they were building.
This is why I am passionate about good ticket writing.
Product managers spend half of our lives in Jira or its equivalent, and tickets are where the communication rubber meets the road with our implementation teams. It's critical that we write good tickets to ensure that the work our teams do is both valuable and successful.
Now, when I say “good,” what I’m really talking about is whether a ticket is EFFECTIVE. When I took on the team above and improved our tickets, we ended up with more efficient refinement sessions, more accurate estimates, better QA, and more engaged engineers and other team members. Are your tickets giving you that? If not, read on!
Why do we write bad tickets?
Incomplete tickets are often created with the excuse of “speed,” as in, “we’re in a hurry so I put the basics of what we need.” Unfortunately, I have never seen it work this way. If tickets aren’t clear, implementation teams are left asking a million followup questions or worse–making guesses on their own about what’s needed. Short tickets generally lead to long build times, or building the wrong things first before figuring out what’s right.
I also find that “speed” is actually a lack of clarity in disguise. I’ve heard, “the CEO wants this NOW” and what “this” is, well, that’s a little vague. So the ticket is vague. So the build is…unsuccessful.
Why do so many companies fall into this trap? Often at a startup, your first one or two implementers will be in the room with your leadership team. They’ll have all the context they need to build what’s necessary. As a company grows, the implementation teams grow in size, and the distance between them and all that context grows significantly as well.
When I consult with a new company, I always take a look at their tickets to assess the health of communication.
Tickets are often written like this:
Example of a Bad Ticket:
Build a report for customers to view their most recent purchases.
This ticket tells me nothing about why we’re building this, what the report should include, where it exists in the context of the customer, or what value we purport to deliver. If I were an engineer implementing this, I’d have a whole bunch of questions, and shipping this code would make me feel like a cog in the machine. One more ticket closed.
Compare that to this:
Example of a Good Ticket:
Our customers have complained that it’s hard to make returns or to reference their orders when talking to customer service, because that information is buried in their email. We think that making this information more accessible will increase customer satisfaction and cut down on customer service calls by over a minute while customers search for this information (saving us money).
Create a new page in the customer profile for “Orders”
Display the most recent 3-5 orders (as many as load quickly) sorted most recent to least
Display critical information for each order:
Date and time of order
Content of Order
If there are more than 3-5 orders, display a “see more” link
At the bottom of the page, display a link to our contact form that says “Need help with your order? Contact customer service.”
As a customer, I can easily and quickly find my past order information
Now we’re talking!! Now I know what problem I’m solving, why, and how. As an engineer, I can make suggestions, like “hey, it’s actually no trouble to load this information for up to 15 past orders, is that ok?” or “What if we put that help link on every order and passed the order information directly to our CS team?” What a value add!
As a product manager, it took me about 15 seconds to write the first ticket, and about two minutes to write the second. I think the extra time spent is worth it, don’t you?
Anatomy of a Good Ticket
At the very least, a feature ticket needs three parts-
Purpose: WHY are you building this? It’s not just good to know, but critical information for the implementation team, who are inevitably going to make decisions about implementation while building that you may not even realize. To provide them with this critical context is to empower them to make good decisions, think through potential alternatives, and feel the value of their work. If this is part of a larger epic, the epic needs to link to your product brief, user research, and anything else that will help provide context around this particular ask. This will convey the value to your customers and your company.
Requirements: What needs to be true for this to be successful? This is where you put all the nitty-gritty little details (IN BULLETS). Try to think not just of the things you need, but also what CANNOT happen. This is the basis for building test cases, so load this up with all the details.
Deliverable/Acceptance Criteria: This should be a plain english way to say “I’ll know this is done when…” Ideally, it fits a user story that’s part of your user story map, like “Our customers can accomplish this task in two steps.” It’s also fine if it’s just a sentence to convey the mood of the ticket. I’ve written acceptance criteria like “Our Customer Service team doesn’t feel existential dread when opening their inbox.”
The first and third sections should appeal to the human element–both the humans on your team and the humans you’re building for. Only the middle section should feel in any way technical. This humanity sandwich will help ensure that you’re being human-centric in your thought process, and will also help you tie the value of what you’re shipping as you ship it.
Sometimes, you may have a conversation while doing your research about how a ticket may be implemented. Oftentimes, engineers will receive the results of this conversation as a ticket that just has the implementation: “connect node A to node B” and that’s the whole ticket. I prefer to add this as a section at the bottom of the ticket called “proposed implementation.” This captures the suggestion or conversation you had about implementation as a starting point for discussion, but makes it clear that this is one suggestion, and that the implementation team that owns the ticket also owns the decision of how to build it.
These are guidelines, not rules
A colleague of mine pointed out the problems of using ticket standards for gatekeeping, which is something you absolutely want to avoid both for your own sanity and for the health of your team’s output. Consider this a set of guidelines to follow 90% of the time. There will always be exceptions.
Some of the product managers I coach start with this method and feel their tickets are redundant, and that they're essentially saying the same thing in each section. If that's happening to you, double check that each section answers a different question:
Purpose: WHY are we doing this work?
Requirements: WHAT needs to be true for this work to be successful?
Definition of Done: How will we know we did the work right?
What about bug tickets? I’m going to save another post for these, because I have THOUGHTS. 🙂
Share your examples of good and bad tickets--I'd love to see!