Thanks for joining us at a Get started with Jira live session! During the class, we dug into a bunch of Jira essentials, but this post focuses on the one thing that causes the most day-to-day friction: tickets without context.
You probably know the type: four-word summary, no description, no due date, assigned to someone who left the team six months ago.
Nobody intended to make this work item useless. Whoever logged it knew exactly what the work was, but they filled in the minimum fields, hit save, and moved on.
What the save button doesn't do for you 💾
When you create a work item in Jira, three fields are required by default: a space to put it in, a work type to categorize it, and a summary. Fill those in and you can save the ticket. Everything after that (the description, the due date, the attachments) is optional, because Jira doesn't need these fields. But people do.
Think of it like leaving a note on someone's desk. The note exists whether it says "call back" or "call Sarah at 3pm about the invoice she wanted on Tuesday." Both are technically notes, but only one is useful.
Beyond the summary line
Let's look at the same work item written two different ways.
Here is a weak version:
Work type: Bug
Summary: Login issue
Description: (empty)
Nothing about it is wrong, exactly. It's just unusable. Where? On what device? Broken how? Does it block anything?
Now here is the same item, written for the person who picks it up next:
Work type: Bug
Summary: Login button unresponsive on mobile after session timeout
Description: On iOS 17, tapping the login button after the session has expired produces no response and no error message. Closing and reopening the app resolves it. Reproducible consistently on iPhone 13 and 14. Not observed on desktop or on Android.
Someone coming to this cold (a different team member, a contractor, a colleague covering while you're away) knows what the bug is, where to start, and what's already been ruled out. That's the test worth applying before you close the tab of a new work item: will someone new understand what to do, or will they have to go hunting for the person who created the ticket?
Leave breadcrumbs in the comments
Once a ticket is in motion, the same principle applies to comments:
- @-mention the specific person you need, so they get notified or can react.
- Link the blocking ticket directly in your comment so the next reader can click through instead of searching.
- Log the resolution. Document not just the fix, but what you tried and why, so the next person with the same problem doesn't start from scratch.
Put it to the test
Find a work item you logged recently, one you created quickly and moved on from. Open the description and read it as though you're seeing it for the first time with no memory of the conversation that prompted it. Would someone with no context know what this is, what state it's in, and what to do next?
If the answer is no, add one sentence that fixes the biggest gap. Just one.
🌟 Then share in the comments: what's the worst work item you've ever inherited?
Keep learning
