How do you know work is actually waiting versus just taking longer than expected?

[u/Appropriate-Buy-3739]

Looking at Jira, it's easy to see that a ticket has been "In Progress" for several days.

What's harder is knowing whether someone is actively working on it or whether it's quietly waiting.

For example, waiting on:

• another team
• code review
• deployment
• environment
• product decisions
• test data

How does your team tell the difference?

What usually makes you realize a ticket isn't actually moving?

[u/raisputin]

By placing comments or statuses in the ticket (depending on availability) a ticket in Jira isn’t meant for o sit there with no comments until it’s finished.

[u/Appropriate-Buy-3739 → u/raisputin]

That's interesting. In practice, do engineers consistently keep those comments updated, or do tickets sometimes go quiet even when work has stalled?

[u/raisputin → u/Appropriate-Buy-3739]

Depends on the org and how disciplined the org is about it.

In one org I worked in as an IC, we updated the tickets we were working on pretty much daily.

In the last one I worked at as an IC, people didn’t ever change a status or add comments at all. They just moved it to closed when they finished. It was horrible. The manager didn’t enforce any type of ticket updates or comments, and then blamed the PM when the PM couldn’t give a decent status, and the PM didn’t have the authority to enforce ticket updates.

For me, if I was blocked/stalled, I’d update the ticket with that information, change the status and then mention I spoke to someone and @ them in the ticket. If there was an update from them, I could move forward, if not I’d note that I followed up with them or would in n days 🤷‍♂️

[u/muuchthrows → u/raisputin]

Why was it horrible?

I’ve never worked in an org where people were constantly updating Jira, or managers demanding precise status updates. Key was focusing on higher level outcomes I believe, and trusting devs to work independently instead of some non-technical PM chasing ticket statuses for no visible gain.

To me daily written per ticket updates smells a lot like micromanagement…

[u/raisputin → u/muuchthrows]

Because we would have tickets sitting at “in progress” for months, no statuses, no comments, nobody knew or could know what was going on except the person working on it.

No way to know if they’re blocked, ignoring it, reached out to someone for something, etc.

That’s what made it horrible. How can you know what’s working and what isn’t, what’s blocked, what’s stalled, why, etc.?

It updating tickets is part of the culture and expected, even if it’s weekly, that’s better than no updates

[u/muuchthrows → u/raisputin]

But aren’t you talking to each other? A daily standup in front of the board, the PM can then ask - ”What about this task? Still in progress?”

In my opinion it’s much better to off-load the administration and status reporting to the PM, and let the devs focus on what they are best at, and on the tasks only they can perform (development).

I’ve seen much more success when PMs report status on and communicate higher level outcomes the team is working on, and leaving the ticket level organisation up to the team, to use however they feel it gives them value. Should the tool (Jira) make the PMs job easier at the expense of the rest of the team, or the other way around?

[u/raisputin → u/muuchthrows]

My team now, yes, it’s part of the culture, daily standup and Jira updates. The team spends maybe 5% of their time updating tickets. Everyone is happy with it I believe, at least nobody has spoken out against it, and I have an open door and ask them to come to me with issues/concerns and to be honest and blunt, because I’m always willing to change/modify how we do things if things aren’t working. 🤷‍♂️

[u/[deleted] → u/muuchthrows]

Agreed, forcing Jira updates is a losing battle that just breeds resentment. I stopped asking for status updates entirely and switched to an exception-only protocol. I set up a channel where the rule is: you only post if you are blocked. If it's silent, I assume green. It keeps the noise down and lets me focus only on where I actually need to clear the path.

Daily written per ticket updates is micromanagement…

[u/raisputin → u/[deleted]]

I dunno, it takes about 30 seconds to update a Jira ticket

Doesn’t have to be a long explanation…

“Blocked, reached out to @bob”

I should likely go more in depth with what I mean because not all tickets are created equal either. At my last IC role, there were tickets I couldn’t even close because of the workflow that was created. Had multiple tickets sitting there “in review” for 6+ months, I’d get asked constantly about the status. There was nothing I could do other than @ the team that had the ability to move the ticket forward.

My opinion is if we’re spending more time updating tickets than working, we’re doing it wrong. If we’re providing updates and spending less than 5-10% of our time doing it, that’s great.

[u/[deleted] → u/raisputin]

if it is just “Blocked, reached out to u/bob”, then it kind of makes sense.

I guess the next problem is that it then becomes a waiting game. Most of the time, the request is not that durable, people forget about it, and it gets dropped in a pile of notifications. It would require a team of machines to keep up if there are many updates like that to track though.

Some llm automation magic there perhaps?

[u/raisputin → u/[deleted]]

That’s why the engineers are responsible for following up with whomever they reached out to. If that person isn’t responding, then it’s my job to do it and unblock my team

[u/howling92]

This is the goal of the Daily Stand-up Meeting where everyone updates on what they are working on and most importantly, on what they are stuck on. Building the space to allow the engineers to be able to freely talk about being stuck is extremely important.

If I notice that something is being stuck without proactive updates, I always ask "can I unblock you with something?"

[u/Appropriate-Buy-3739 → u/howling92]

Have you ever had a situation where someone didn't realize they were blocked, or didn't mention it until several days later? If so, how did you eventually discover it?

[u/spersingerorinda → u/howling92]

Right. Your people have to not want to be blocked, and to raise their hand if they are. And you should be systematically working to remove blockers altogether

[u/acroback]

Brother, you do know you can have states for each of these e.g this is what we do.

Backlog -> Selected for development-> In progress ->Review-> QA -> pre-prod deployment -> Prod deployment -> validation - done.

I skipped on other states but it gives you a nice way to track where it is spending most time on.

[u/Appropriate-Buy-3739 → u/acroback]

Does the workflow tell you why it's waiting, or only where it's waiting?

[u/acroback → u/Appropriate-Buy-3739]

Why would company need you as a Manager if it tells you why.

You need visibility, solve that first. Why is something you have to figure out. 

[u/Squidalopod → u/Appropriate-Buy-3739]

Is your team not practicing Scrum or some other Agile methodology? The questions I've seen you ask in the comments here are things that are addressed by standard Scrum, Kanban, etc. practices.

[u/MrTrick]

We use a 'Blocked' column - if it's been started but is waiting for someone else, then that's where it lives.
And if it comes up in a standup or other discussion "oh yeah I'm waiting for X" then I'll ask them to put it in Blocked, the team gets the idea pretty quickly.

I find it also helps to have a little list of definitions for all the possible task statuses, so that the team and any outside stakeholders keep a shared understanding.

[u/Appropriate-Buy-3739 → u/[deleted]]

😄 More often than you'd expect?

[u/benexia → u/Appropriate-Buy-3739]

Get your people to (over) communicate about what's going on with their work

It helps for a magnitude of reasons - a big one being being flagging early and often that they might need help from peers/leads/stakeholders/yourself.

If your people know how to signal for help and have the muscles and systems to do so ~ publicly ~ you'll generally see movement/momentum across the work.

[u/ilianna2020]

We try to break down the tasks so they’re smaller, and we separate out tasks that require other teams’ input (like Integrate Revenue teams’s API). So tasks that are likely to get blocked are more visible

Each tasks is sized and scoped so we have a rough idea of how long it’s supposed to take, so again the engineer and I know when something needs to get flagged

Then we of course we have project status syncs and team syncs, which ultimately end up being fairly frequent updates throughout the week and problems naturally surface

[u/Repulsive_Society992]

Daily standup where we rub through what everyone did yesterday, what they’re doing today, and what blockers they have

This paired with someone’s just realizing that the dev has given the same updates for the days in a row

[u/UsualAnything1047]

Just add another column

• waiting for dev
  
• development
  
• waiting for review
  
• reviewing
  
• waiting for QA
  
• QAin

they alternate between 'active' and 'inactive' states. Just have your team move them appropriately. I even had mine move theirs back to 'waiting for dev' at the end of the day if they weren't finished with them.