Bad Tickets (Work Items according to Jira) = More Meetings

[Evan Fishman - Quely for Jira]

Long meetings are a problem, but not THE PROBLEM

The root cause is invisible on the board

Tickets/ Work Items that can’t answer their own questions.

When a ticket is vague, the team fills the gap with meetings, side threads, and endless “quick” calls.

The Hidden bill:

Flow broken → slower cycle time. Every interruption resets your focus.

Same “So… what does this story do?” conversation. Every. Single. Time.

I use 3 questions to evaluate every ticket:

🟣What’s being built?
Clear acceptance criteria a junior dev can follow.

🟣Why does it matter?
One-line user or business outcome.

🟣What matters most right now?
The single non-negotiable (performance, pixel, edge case).

If a ticket fails any question, it’s not ready. Period.

Rewrite it before you schedule another call.

[Stephen_Lugton]

We're having an issue with this at the moment; we've got a new tech lead on one of our teams and he hasn't fitted in as well as we'd hoped.  

We're getting good detail from our PO as ideas in JPD on why we're doing a piece of work, with business value and high level deliverables, but translating that down to workable work items has been challenging.

The ask for the tech lead was to take the approved JPD idea, work with the team and other team leads e.g. DevOps and architect the work.  The idea was that we would then refine the work with the team to create individual work items so that the team, especially the junior devs, could understand the work and know what was expected of them.

Unfortunately, the tech lead, instead of guiding the team on technical aspects has been creating all the work items with confusing descriptions, doing a lot of the interesting work himself (especially frustrating when we want the rest of the team to learn by doing on those specific areas), then telling the team what the remaining work items are (without discussing how they could be achieved) and leaving them to it.

I had been instructed to not get involved and let him sink by himself!  Although we have been helping out the team members who have been struggling behind the scenes.

Now, however, I've been put in the position of acting as a 'blocker' between him and other teams and been told I'm allowed to coach him on work item creation and how to actually be a tech lead for a team rather than just a senior tech dev.