Writing out tickets adds flexibility to teams. It ensures any team member can work on any ticket, helps accelerate teams, and generally improves the quality and traceability of product and technical decisions. Make sure the time spent is high value.

Transferring knowledge

Writing tickets might not be your team's focus when validating your minimum viable product (MVP). You want to go fast, and the team is small enough to simply discuss what needs to be built. The task board works as a planning tool.

But then the team starts to grow. Each newly added team member requires a lot of effort to onboard. Hours and hours are spent explaining the context and why the application is structured the way it is.

Wouldn't it help to have a history of decisions? Well-written tickets and feature passports can help newcomers gain the context they need to make an impact.

Another scenario: the two most complex parts of the application have been developed by the same team members for some time. But now one of them is leaving the company, taking the knowledge of the inner workings of that crucial feature with them.

How could you have avoided it? A key heuristic is to look at how many people actually worked on a feature and properly understand how it works. This is only possible when anyone can work on a feature — and that requires a well-written ticket.

Remembering the past

When a bug or technical debt comes in, an initial instinct is to figure out how the application is supposed to work. But that's hard to do unless you have a written record. Upon investigation, many teams find that engineering and product have different ideas about how something is supposed to work, especially for an edge case.

Priorities also change as your team's market understanding changes. But shifting priorities mean the team may have to abandon work on a particular feature to speed up the delivery of something else.

When the abandoned feature is picked up again, does everyone still remember the decisions behind each ticket? In this case, you will lose time performing research again or rehashing conversations.

Go faster

As your product starts to gain traction, the team becomes too big to involve everyone in every meeting about a new feature. Maybe your daily standup is hardly about status anymore. It's a meeting with a dozen people — completely distracted by something else — while two or three folks discuss the latest issue's ins and outs.

Sound familiar? The solution is to spend more time writing detailed tickets.

Maybe development has been slowing down for some time. Features get built, but finishing them takes time. Some teams add a dedicated Quality Assurance analyst (QA) to test the app with each new feature. But the speed of development does not increase.

The reason for this is that the tickets are unclear. There is no shared understanding between the product, team, developers, and QA, so topics must be revisited repeatedly to get things right.

Don't do too much

Of course; it's a balance to write good tickets. Keep the essential goal in mind: document enough for others to understand the desired outcome. That does not mean every task requires a ticket with several pages of text. Finding the right balance takes some practice.

Collaborating on the creation will make it easier to record the most important details without the fluff. Also, avoid writing all the tickets upfront or choosing one person to write all the issues. These are not good investments of time since you'll end up closing or deleting many of the issues once development begins in earnest.

In the end, the developer is tasked with translating the proposed solution into code. We've seen tickets with pseudo code so close to actual code you might wonder why they did not simply add it to the code base instead. It is indeed a balancing act and what level of detail you need in tickets is for the team to decide.

We hope this gives you a new perspective on creating tickets and why you should spend time doing it. Trust us; it will pay off in the long run if you get the level of investment right.