3

I'm using Agile views/boards in JIRA to manage issues of a project. Is there a mechanism to signify issues that are important (hence high priorities) but for technical difficulty and human resource availability are currently in a sort of stalled state? In other words, the tickets has not been updated for a long time. I want some way of flagging those tickets.

Improve this question
2
  • Would this be more suited to SuperUser SE (superuser.com)? At present it is a question about reporting from a defect tracking system and thus not particularly a project management issue.
    – Marv Mills
    Sep 10, 2014 at 12:45
  • I just feel audience here will have much better chance of having some expertise and experience with project management and JIRA.
    – qazwsx
    Sep 10, 2014 at 23:43

6 Answers 6

Reset to default
3

From any JIRA Agile view (Plan or Work), you can simply right-click on a ticket and select "Flag" (or something that sounds like "Flag as Impediment", I forgot a bit now).

Alternatively you could write a JQL Query like:

Project = "project_key" and Status = "the_status" and updatedDate <= "-5d"

This will give you all the tickets in a Project in a certain Status and that have not been updated for more than 5 days.

Good luck!

Improve this answer
2

The agile part of Jira in fact is still an add-on to the base Jira application. It uses a workflow system to define what processes a task should go through. You can create a workflow scheme for you Agile/Scrum items to move to a new state once no action has been done to them. I believe this is possible. Sadly I have no applied experience aside from a "course request" workflow set up recently.

The schema's can be found under administration > issues > workflow schema's. Note that you'll need to apply the new schema to the correct project. You can easily test whether your wishes are possible by applying the 'work in progress' schema to a temporary project.

Improve this answer
1

Apart from internal JIRA mechanisms such as (obviously) sorting by creation date, I advise practicing the Zero Bug Policy:

  • When you receive and triage issues, it is important to label them or include them in an Epic.
  • At each sprint planning, you pick a dozen in a list of 40-100 issues related to your Epic/labels. Don't include stalled issues. Only include issues that you are confident you'll complete during the sprint;
  • Your stalled issues naturally stack at the bottom of the suggested issues for your sprints,
  • At the end of a release period, the best practice is the zero bug policy: Take a decision about your stalled issues. Your clients know that, in fact, there's nothing you will realistically do about them. Close them as "Won't fix". It's an exercise about sincerity and accuracy.

Sorry to bring that up. A 1000-issue backlog brings discredit on your decisions and drags unnecessary brainpower off your teams. Once you succeed to close them, projects feel light and fresh again.

Improve this answer
1
  • I understand the rational. A lot of the stalled issues in my current project is actually stalled because it needs action from some developers who're primarily spending time on other projects, so even though the task is important for my project, its relative importance can be (viewed as) low for the developer. Is resolving as "Won't Fix" really the ideal solution?
    – qazwsx
    Sep 10, 2014 at 8:16
1

JQL in JIRA is very powerful, and I used a very similar query to filter out tickets that are high priority and are stalled.

Project = "your-project-key" AND Status in (Open, "Needs Verification", "Ready for Review", "To be reviewed", "Needs Triage", "Awaiting Review", "Under Review", ToDo, "Open - untriaged", Parked, "To Do") AND resolution = UnResolved and priority in (Blocker,Critical,Major) ORDER BY updatedDate
Improve this answer
0

I'm no JIRA expert, but i guess you could just add a specific label to your issues. It would allow to filter on this label if you want to hide those issues.

If it is deeply linked to your process, and you plan to use it often, you could even create your own field, but it would imply to tweak your screens…

Improve this answer
0

If there's a specific ticket (or if there should be one) blocking another one, I make liberal use of linking tickets together with the "blocks" relationship.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.