Bread & Butter: Ticket Best Practices

There are thousand ways to do it and almost no right nor wrong. But let's take a look at some best practices when writing epics, user stories, bug reports and so on.

Prologue

Before diving into it, let’s face one thing: You will be judged for the quality of your tickets, especially as a new PO. Just like an English teacher will be judged by their grammar if they write a text — lucky for me then I’m not a teacher.

But also, let’s get straight: Tickets are merely a way of transporting the idea of a product to your team. So, if you get your idea across well or work with a highly self-reliant team you don’t even need tickets or your teams write them themselves: Nowhere it is written that product people need to do this. At some great companies, you often won't even need to write tickets. For example at facebook there are product managers who never wrote a single ticket - mindblowing, aye? In a way that's actually the way it's meant to be. Your business should be to explore user needs, to find problems worth solving. Unfortunately, reality in many companies is different, and some even drive it so far as to reduce POs to Delivery Managers.

And so, in reality writing tickets is the bread and butter of the job for many POs. And sometimes you even need them for documentation purposes, such as in health or fin tech, when authorities or other institutions check upon your product regularly.

However, when writing tickets always keep in mind: You first write tickets for your team — not yourself, not management, maybe auditors if your industry requires it. So, the best tickets are the ones your team can work with best. Ask them what they need and continually improve.

Yet, here are some best practices across a wide range of ticket types, that might help you write better tickets. Try them out, combine them with your own best practices, leave feedback and find you own blend that works best for you.

1. Include Objectives in your Backlog

OBJECTIVES are not the standard ticket types you face on a Jira Board, I know. But hear me out because lots of POs know this situation: Some outside stakeholder - often management - knocks on the door and asks that some feature definitely needs to find its way into your product, maybe because competition already got it or some investor demands it. It messes up your plan and a few month later management comes back and ask why you're behind schedule or didn't achieve certain outcomes.

Companies at which this happens often don't work with OKR or do a poor job at it. This article is not how actually make OKR work. But maybe think about including OKR into your backlog as a kind of top-level-ticket-type. This will not only help you trace all tickets back to your highest level objectives, and thus makes it easier to check if what you work on is actually aligned with your goals. But also it makes it much easier to prioritize tickets according to these OKR. And - if done right - it's super transparent to all stakeholders and you don't even have to create stupid powerpoint slides (better use www.pitch.com anyways) or put effort.

To make a plastic example: Create a issue type - maybe call it 'OKR' - as a top-level ticket type. For each objective create a OKR-issue. Say your building a medical product which allows users to add and share medical documents with their physician. An objective here could be to become compliant to some law by the end of the year and the corresponding key result would be to fulfill all 'must have' requirments of some authority which check whether you fulfill the law. Now, link all initiatives or epics that pay into this goal to this OKR-ticket. Done well, each initiative or ticket should be clearly and (usually) unambiguosly be tied to one of your objectives. If this is not the case, often times it's a sign of your OKR being to ambiguous.

example

Of course, there are plenty tools out there which help with this as well, such as Productboard. But if you don't want to spend loads of $$$ on them just use Jira to keep track of your objectives.

2. Work with Initiatives

In case the gap between epics and your goals is too large, or your epics are very granular (as I will advocate for later), think about creating a "in-between" level, called INITIATIVES. Initiatives are high-level efforts that immediately pay into your objectives. Ideally, each initiative pays into one of your OKR.

Given our aboves example of our medical product, an initiative might be to enable users to allow physicians to access their documents in their record. As product managers, it's your job is to uncover these initiatives, find out how impactful they might be towards your objective and prioritize them.

example

initiatives are perfect to bridge the gap between objectives an epics

Creating roadmaps out of initiaties

The great thing about initiatives is that they are the perfect granularity to create roadmaps out of. Given you have a set of initiatives, wrap them together into a 'now', 'next', 'later' roadmap or even a Gantt-Chart using Jira Plugins, whatever you work with. This way you don't need extra tools for it and can very transparently create roadmaps which pay into your objectives.

image credits to Atlassian. Imagine those epics were initiatives. And see how the Atlassian crew does not use best practices with their epics? They use them as containers to just throw stuff in... read the next chapter to learn how to do it better ;)

3. Epics Best Practices

Do not simply use epics as containers to throw your stuff in. This is what many product managers do, even at companies who do a great job overall as the example above with Atlassian shows.

Instead, use one epic per use case. Use cases can usually be clustered into so-called CRUDD actions (a classic):

• Create

• Read

• Update

• Delete

• Download

Let's take our medical product again. In our initative we want to enable users to allow physicians to view documents they uploaded. On the frontend side of your user the epics which make up this initiatives could be to enable users to...

• add physicians to their list of viewers

• view this list of physicians which are granted viewing rights

• edit entries on this list

• delete physicians from this list

• download doesn't seem to make much sense in this case, but you never know

• ...

Of course, this initiatives needs a fitting counterpart on the product which physicians use to view the documents of their patients: To allow physicians to view the documents of the patients. Epics that could make up this initiative might be to enable physicians to

• add documents to their patient's record

• definitely view documents to which they are granted access

• edit some of the entries

• probably not delete documents

• but likely to download documents

This seems to be very granular, but it makes sure that each epic is clean and does not bloat into a 30-or-more ticket monster. If you think through each of these use cases, down the road a whole load of stories could still pour out of them. But also, organizing your epics with the help of the CRUDD-actions perfectly fits with another commonly used organization scheme on user story level, which we will take a look at later on.

Put resources into your Epics

Now, to let your teams work best with epics, make sure they got everything in there they need to work - and nothing more. Nobody needs implementation details here. Instead, only put what is needed is to get the gist and overview of the use case. These usually are

a) User Flows Diagrams

b) Technical Flows like Data Flow Diagrams

c) Clickdummies / Prototypes, if any exist

d) System Diagrams and any other architectural context beneficial

Again, if you’ve got the time, be service-oriented and link them directly from the resources your teams work with, then your teams don't have to. But it's also not a problem to let them link it - after all, they know best where they store their deliverables.

4. Best Practices on User Stories

If you use the CRUDD-scheme on epics, there is another acronym you might want to learn about: WEESLD (pronounced “weaseled”). WEESLD basically is a helpful pattern to organize the stories in your epic:

• Waiting

• Empty

• Error ← THIS IS VERY IMPORTANT

• Success

• Limits

• Default

For me, I often adjust WEESLD a little bit, but you know: Do whatever works best for you. If you look at each epic as a feature, each such feature should have an entry point and an exit point, and between these two the WEESLD magic happens. For many products stories in an epic usually form an arc like so:

• Entry Point: e.g. user clicks some button which navigates her to this feature

• Loading State: e.g. display loading state while BE operation takes place

• Error State(s): e.g. display error and debug action if result couldn't be delivered

• Empty State: e.g. if no database entries for a request were found

• Success / View State: e.g. a confirmation that server successfully deleted a database entry as you requested or display content of a document

• Exit Point: e.g. an ‘exit’ icon through which users are navigated back to other pages

Of course, this pattern doesn’t hold true everywhere, but I found this to be very repetitive for most features on most products in most companies I worked for.

User Story Titles

Most POs write their tickets solution-oriented, something like this:

or: 

This is fine in some contexts. But actually, as PO the solution space should be none of your business. Finding solutions to problems is the realm of your team: Designers, Developers, Content Developers etc. define how a product should look like and work. So, if your write your tickets in solutioning style you always — at least implicitly —mess with their ownership and in the worst case even limit their space to be creative.

In the above's example I already told the team that they should use a password as a first factor for a user to authenticate. But there are so many ways for users to authenticate: magic links, paired devices, biometrics, etc. Same with logout: I didn’t mention what problem this is solving: Do we want to enable users to manually end the session so that they are offline and — e.g. — don’t receive any notifications? Or do we automatically want to end a user’s session after some time to add a security barrier?

As PO, your job is the problem space: To find problems and judge, which ones are worth solving and in what order. So, maybe state titles in problem style, maybe even as user stories, like so:

Yes, this might take some time to get used to. But it will not only empower your team to take ownership of the solution and make them more creative. It will also sharpen your view of the problem space and makes you think more in problems. As a result, you will naturally be more attuned to user needs and it will make you a better PO — I promise!

Add Resources to your User Story

In your ticket body, think about what is essentially needed by your team (or auditors) and cut everything else. You don't write tickets to win lyric competitions and you don't want to steal your team's precious time. So, think: "what does my team really need to get the job done?"

Link the most common design specs your teams work with

• wireframes

• any special elements — such as Icons or Loading Spinners — which your UI library does (not yet) contain

and the most common tech specs they need to do their job:

• endpoints to be called

• request formats

• response formats

if this is all captured in a neat api docu, link it. There are plenty more resources to add, depending on what you and your teams work with: Localization files, link to CMS content or endpoint of the tool you're using to draw from, non-functional requirements, legal requirements ...

Write Acceptance Criteria in Given, When, Then style

Now, this is the juice. This defines the scope your story. If done well, you can save any QA Engineer in your team massive time by formulating your acceptance criteria as test cases, e.g. in Given-When-Then format (read →this great article to get the gist of it). For example, a story which describes to select and confirm the deletion of one or multiple documents could contain the following Acceptance Criteria based on the specs your teams have defined:

Ideally, write the AC together with a QA Engineer. They have a great eye for things that might happen along the way which you would never have thought of in the first place.

5. Sub-Tasks

Best practice: Don't touch it! Leave the sub-tasks to your developers, so they can work with it best.

The examples above are usually linked vertically to each other. But there are also lots of other commonly used ticket types on the same level as a story. Let's have a look at some of them:

6. Bug Ticket Best Practices

Ja, your teams don’t produce bugs, I know, mine neither ;). But I heard that improved ticket quality negatively correlates with numbers of bugs to fix — just a rumor, though 🤫. To help your QA Engineers investigate the root causes or at least reproduce any bugs, this format is almost universally well accepted these days:

a) Description

Provide a high-level description of them problem.

b) Steps to Reproduce

Clearly and detailed, walk the ready through all the steps you’ve taken to get to the point where the bug occured

2. clicked on X

4. selected option Y

6. confirmed selection

8. …

c) Expected Outcome

Write what outcome you would have expected after going through above’s steps. You may use user story format, so that you can provide context on what you ultimately wanted to achieve and what kinds of users may suffer from the same experience.

d) Actual Outcome

Describe what actually happened in contrast to what you expected.

e) Environment

Don’t forget to provide some details on your environment. Desktop OS, Web Browser or Mobile OS? What Version? Any other relevant variables?

7. Technical Tasks

Sometimes, teams use Technical Task and Sub-Tasks interchangably. But if you read our post on Backlog-Best Practices (if not, read it here), you know that Technical Tasks are a pretty neat way to capture technical debt. Best practices on these tickets are then best to be left to your tech leads who should take care of this.

8. Spike Tickets

Sometimes, particularly if you're building a product which has never been built before, using new technology, have a junior team or anything else, lot's of tasks you take on require some research or proof-of-concepts before going to proper conceptualization or implementation. Use a separate ticket type to indicate what needs to be investigated so that you can clearly separate the tasks which are ready to be worked on from the ones which are not clear yet.

To indicate such as "to be investigated" state is also beneficial with bugs. If a certain bug has not yet been replicated or you want to find it's root cause instead of performing a superficial fix, you can use this state to be able to distinguish the bugs which may find their way into your next sprint from the ones not.

There is no best practice way to write spike tickets, it depends very much on what you want to achieve with it: a POC, replication, etc. But maybe it often makes sense to formulate their content as hypotheses: If ...., Then ... But yeah, that may not apply to a broad range of these tickets.

Now, these were some best practices which helped us to better equip our teams to enable them to do their best work. These may not apply in all cases, but pick the ones you deem helpful and blend them into your own ways of work, and skip the others. Most importantly, keep in mind:

• The better aligned you are with your team, the less time you need to spend on sophisticated tickets

• Don't write novels: Only put the stuff your team needs to work with, otherwise it gets messy

• Continually ask your team for feedback to improve ticket quality

Got questions, ideas or remarks on this method? Join the conversation on

Slack