7 Ticket Anti-Patterns to Avoid
If you want to deliver on time, avoid these 7 mistakes when creating jira ticket
Ticket is the founding document which holds information of the work we need to carry on.
Whenever we start adding a new feature, making improvements, or fixing a bug, it always starts with a ticket.
These are the 7 anti-patterns you want to avoid
1. Ambiguous Ticket
This ticket has a broad description and vague acceptance criteria.
Because of this, developers may interpret it in many different ways.
Completing the acceptance criteria can feel endless, as it involves addressing multiple interpretations.
As a result, developers may get stuck on this task for weeks.
2. Oversized Ticket
This ticket contains many acceptance criteria.
Large tickets are slow-moving.
Takes too long to develop (3–5 days)
Takes too long to review (harder to review large PRs)
Takes too long to receive feedback (requires waiting 3–5 days)
Takes too long to address, especially when there is a lot of feedback
Difficult to manage
Hard to estimate (because it has many moving parts)
Hard to prioritize (because it must be handled as a whole and smaller parts cannot be deferred)
Risk of being marked incomplete if even one small part isn’t finished, no matter how much progress was made
3. Unplanned Ticket
This ticket was added only during the sprint.
To accommodate it, you need to choose and move existing tasks to the backlog.
Fortunately, if there are existing tasks that aren’t very important, this is manageable. However, if there are none, you are left with no choice but to deliver issues with insufficient time.
This usually happen if the devs are new to the tools, process and concepts needed to deliver the solution.
4. Untestable ticket
This ticket has no clear acceptance criteria.
Testers are left guessing whether the issue is truly resolved or not.
This can cause delays, as the ticket might remain pending in testing for too long.
If it can’t be tested, it can’t move to the next phase, which also delays feedback.
5. Undefined UI Ticket
This ticket has no mockup design.
It is easy to agree on how it should function during planning but during testing everyone has their own expectation how it should look like.
It would result in two things
Delays - overhead from negotiation between different people
Rework - after they agreed, there must be an adjustment and additional testing
6. Non-Reproducible Ticket
This ticket has no steps to replicate and no clear expected outcome.
The problem with this ticket is that it leaves you guessing and relying on trial and error until you run out of time, instead of fixing the actual bug.
What’s worse, you might spend time replicating the error only to find out it’s not actually a bug.
They might have misunderstood the expected behavior.
7. Open-ended ticket
This ticket has no due date and it seem harmless at first.
The task silently steal time that supposedly allocated to your other tasks.
The problem usually arise at the end of sprint
To compensate it might result in 3 things
you need to rush the other tasks compromising their quality
you might work overtime compromising your work life balance
you might remove the tasks from planned scope compromising your boss trusts
Make sure each task has realistic due date and all of your tasks are take into consideration before committing