The care and feeding of tickets

I can be kind of a stickler about leveraging the ticket/issue tracker in software projects (which always seems to be Jira these days, but nevermind that). I write tickets carefully; I link to related issues; I add comments to note the status of work in progress, or to record info that’s important to the work to be done.

I’ve always appreciated having teammates who take the care to communicate clearly on tickets.

Sometimes though, especially when things get busy, ticket creation and grooming can get neglected. Tickets get treated more like obligatory post-it notes than as the key communication channel they are.

Here are some of the things I’ve seen go wrong when the work spec, i.e. the ticket, isn’t good or complete:

• Implementation matches what’s in the developer’s head, not what’s in the product owner’s head.
• Developers spend time fixing or building specific things they think are part of the request, but which could have been skipped or simplified.
• Bugfixes seem to work, but later are found to be inadequate, because the task description didn’t include good reproduction steps for the actual problem.
• The task takes longer than it could have, because there are many rounds of “no, do it this way” feedback and revision.
• If the code/feature is revisited later, developers and product owners may still have different conceptions of it, which will again slow things down and make bugs more likely.
• The developer is frustrated because they have to make guesses to complete their work, and some of their guesses are wrong.
• The product owner is frustrated because they are not getting what they want as quickly as possible.
• Product owners may feel like developers don’t know what they’re doing.
• Developers may feel like product owners don’t know what they want.
• Team leaders have to spend time figuring out where communication went wrong, and spend time getting the team back in sync.

So, don’t treat tickets as obligatory post-it notes. They’re the most important communication channel about changes to your product. Make them badly, and the work will suffer. Tend them well, and your velocity will rise while your bug count drops.