Suggestion: Snooze for Jira tickets

[Mohammad Norouzi]

Hi. We all faced those type of Jira issues that get blocked for some nasty blockers or we cannot proceed because of capacity, or perhaps some third party library is still incompatible and we are waiting for them to release which we don't know when that will be. Or maybe we just decide to give some tickets a rest for a few months.

The problem is that these tickets get lost, you know the saying out of sight, out of mind? 

It's hard to manage these tickets and you all done that when you keep moving them down the backlog and when we see them we surprisingly look at each other wondering  why such an important task is down there!

I think here a snooze functionality comes into picture. I love it in my GMail, when I get a bill email and I don't have time to pay it, then I snooze it to bring that up over the weekend. 

Or when I get that event ticket online and it's for next month, I snooze it to come back to my inbox 2 days before the event so I don't miss it. Believe me I missed some events just because I forgot it.

So for Jira, I can give you an example. We wanted to upgrade to Spring Boot v3.x.x but this library wasn't compatible so we said okay let's look at this in 3 months and check if they released a new version. But who's going to remember that in 3 months? I don't even remember what I had last night for dinner. 

Or many other tickets that are blocked.

Anyway, you now know what I'm talking about? A snooze functionality with some "hint" or "reminder message" that comes up at certain configured date/time and we can easily put that in the next sprint. That increases productivity and is very useful. What do you think?

[Tom Arnautovic]

This would be useful for us as whenever we do the Kanban board, we end up discussing the same items which are blocked knowing that they will be blocked for some time to come.  Would be good if we could snooze an item to a particular date, so it is hidden or clearly flagged with a date when it will become relevant again. 

[Randy O_Neal]

So... there's a terminology issue here, as well as a process/practice issue.  First the terminology...

BLOCKED:  For my organization (and I could easily argue should apply universally, but I won't push that point here) - implies the team cannot move forward on the issue without assistance from someone in a position of leadership - the Scrum Master, the PO, the director, or someone else higher up in the food chain.  Consider such issues as "I cannot proceed on this in progress work until I have X", where X might be an upgrade to a particular tool, access to a particular database, an upgrade to an operating system, a password for access to some otherwise inaccessible resource, etc.  It falls to the Scrum Master - first and foremost - to do anything in his or her power to unblock the team member - that is the charter of every Scrum Master.

With this definition in mind, the team never brings an issue into progress when they know the issue will be immediately blocked; if the issue is blocked and sitting in the To Do or Ready column (we use Ready rather than To Do, but it maps to To Do), it still falls to the Scrum Master to seek remedy for whatever is blocking the issue... but given it is not In progress, the urgency may be less than if it were in progress.

ON HOLD:  On hold is not blocked; it is considered Ready, but the team intentionally chooses to delay working on the issue; this may be due to competing business priorities, changes in business focus, or any number of factors.  In my humble opinion, anything sitting in the Ready column is by very definition "on hold", though it may only be on hold for the next hour or the next day.  One of my teams insists on maintaining an On Hold swimlane; this is essentially limited to Product Owner discretion.  Personally, I despise this approach; a properly prioritized backlog is - for all intents and purposes - filled with work items which are on hold.  The issues are in priority order, and - if the issue priority is insufficient to justify the team's immediate attention - is filled with work which is implicitly on hold.

Practice: It is the first and foremost duty and responsibility for the Product Owner to maintain a properly groomed and prioritized backlog of work for the team to consume.  If you have work that is at or close to the top of the priority order which is actually blocked or in need of being "snoozed", then it seems to me a conversation between the team and the Product Owner is warranted.  In Scrum, the Product Owner negotiates with the team for the scope of the upcoming sprint, with the understanding that the work requested represents the highest business priority/value work.  In Kanban, this is also true... but at the issue level.  The team must have confidence that the issue at the top of the Ready/To Do column is the next most important issue to be addressed by the team.  Introducing an intentional "snooze" is an anti-pattern, and is not an industry best practice.   Cycle Time is an important factor here, not only for Kanban but Scrum as well.  In Scrum, the team is never supposed to commit to work they know/realize they cannot complete during the upcoming sprint; in Kanban, you never begin work you know you won't be able to complete for some indefinite period of time.

Much more could be said here, but I'll leave it at that for the moment.  Happy to discuss further if you have questions or concerns.

[Francesca Hart]

Hi

@Mohammad Norouzi did this ever get raised as a feature request or?