Why do my issues disappear from Epic Swimlanes in JIRA? - jira

I have issues that show up in my JIRA project's backlog page, but they disappear when my board is using Epic Swimlanes. If the board is configured to use any other swimlane option, these issues appear on the board.

This bug has been in JIRA for almost a decade. Every JIRA board using epic swimlanes is quietly hiding all issues linked to any epic that isn't included in the board filter. It's also impossible to use JQL to query for the epics associated with a set of issues so you might include them in the board, which means epic swimlanes are effectively broken for everyone (keep your spam comments advertising paid add-ons to yourself, please).
Because Atlassian makes bugfixing a popularity contest, please consider upvoting these bug tickets:
https://jira.atlassian.com/browse/JSWSERVER-11318
https://jira.atlassian.com/browse/JSWCLOUD-21601

Encountered this issue myself. The solution I found was to edit to query to include the Epic in the board filter explicitly using JQL, and then using the sub filter to remove it again.
Seems to allow the tasks to then appear.

Related

Close Jira Swimlane after last subtask is closed

Currently we use swimlanes based on user stories. Having a lot of stories with subtasks makes the board quite unclear.
Is there a way to remove the swimlane for a story where all subtasks have been closed? That way they would return to the "Closed column" and make the board more overseeable. (We close the user story based on the transtion of the subtask, that is not my question.)
If your Stories are closed, you could just add "AND Status NOT IN ('Closed')" to your swimlane queries. As it is, I think you'll need an addon; this is a lot like other questions about searches based on linked issues. See JQL to get blocked Issues and How can I find a list of all tickets that are linked to issues that have been resolved?

Grouping in Kanban Board TFS 2015

I have user stories on my User Story board. Can I group them by Feature? Please help.
As an alternative, you can add tag for the User Story, then set the tag colour to emphasize selected tags.
Another way is to add swimlanes. When you add swimlanes, you can visualize the status of work that supports different service-level classes. You can create a swimlane to represent any other dimension that supports your tracking needs.
In TFS 2015, you should be able to group your User Stories underneath Epics.
If you are not sure how Epics, features, user stories and PBIs relate to each other, I found this helpful:
https://stackoverflow.com/a/30579669/9046539
The general consensus is that:
Product backlog Item is something that can be delivered in a single sprint.
Feature is something that can't be delivered in a single sprint, but that can be delivered in a single release.
Epic is something that transcends releases.
Theme is a cross cutting concern.
Theme is generally implemented as a tag in TFS and VSTS.

JIRA: Epic issue that can last for multiple versions and "Affect versions"&"Fix versions" fields

I have a project.
It is a web-site.
The project has just started.
I found reasonable to group all design-related stories into one Epic called "Design"...
BUT
...At the moment I started to fill "Design" epic JIRA card I caught myself at being not sure how to proper handle the epic over versions (especially looking on "Affect versions"&"Fix versions" fields).
The problem is:
from one side this epic could be strictly planned in version 1.0 and finished in this version. In this case the epic should contain only design tasks for version 1.0. The question: how to organize design stories that are beyond version 1.0?? With this approach I cannot put them into this epic. So, where?
from other side I can place all design specific stories (despite versioning, 'cause some of them are planned to 1.0 release, others are known but planned to further releases) into the same epic. But in this case how to fill "Affect versions" & "Fix versions" fields? How to organize stories inside this long lasting epic?
Personally I feel that the latter option is better but I would like to listen for your thoughts.
I would separate the design epics in to smaller themes that will allow easier planning per version. For instance, you could have an epic for the header and that would hold all the stories needed to design and develop the header. I advise against putting everything in one epic. The version needs to show what was released on that date. By having an epic span versions, it will get confusing to see what you released. Here's Jira's definition:
A version is a set of features and fixes released together as a single update to your product. Assigning issues to versions helps you plan the order in which new features (stories) for your product will be released to your customers.

Using JIRA Agile for Scrum (from a Rally user background)

I have been using Rally for Project Management in my previous organization, and now I have to use Jira Agile for the same job in the new organization. I am having hard time understanding the way JIRA Agile works, and could not get a hang of the tool after a week of struggle. I am sorting expert help for what I would like to achieve. I have been using JIRA for many years as a bug logging tool but not as project management software.
All I want is to create an Epics and Stories, schedule it into a particular release or sprint. On Rally this is straight forward. Few images attached here.
I could also see the burn-down once I do the above setup, and the developers/qa start burning down or burning up the hours.
I could not achieve the same on JIRA. It asks me to create a scrum board, but I don't have a clue on how to add the child tasks to a story without creating a new child task (which I don't prefer as the tasks were already created and few started progressing).
The scrum board is also not the way it is on Rally, as it does not list the stories but directly shows the tasks which I am unable to correlate with the story. Can any one point me to a proper tutorial or assist me based on your experience in JIRA? Thank you in advance.
I can recommend two things that might make it a bit more easier for you to transition from how you structured your projects before: the Jira plugin "Structure" and using epics, stories and sub-tasks in a defined and controlled manner.
About the plugin: Structure allows you to define a structure, a container that may even span multiple projects, and lets you put issues in. Secondly, and more important, it allows to create any number of sub-task levels. You can use the structure view to show and hide sub-levels, or if you use the agile boards you can just apply a quick filter to the board.
The same goes for using epics, stories and sub-tasks, just make sure everyone able to enter issues follows the same criteria and then add some filters.
Hope this helps a bit
You may want to look at https://confluence.atlassian.com/display/AGILE/JIRA+Agile+101 - it should cover most of the basics to get you going.

How do you create user stories and tasks in Jira / GreenHopper?

We are using Jira / GreenHopper to run our sprints on a Scrum team. The fact that Jira is a bug tracking tool and GreenHopper is a Scrum-ish add-on is becoming painfully apparent.
We want our Product Owner to enter user stories in Jira/GreenHopper and have the team hang technical tasks onto the user stories. How does one do this? Jira/GreenHopper does not seem to have any notion of user stories with tasks. Is this correct or am I missing something?
Also, we want the task board in Jira/GreenHopper to track the user stories and tasks as they move from To Do to Done. Again, there seems to be no way to do this. A User Story is Done when all of its tasks are done. Tasks should be able to move from To Do to Done while the User Story is In Progress. Are we correct in thinking that the Jira/GreenHopper task board cannot do this?
I am generally interested in any thoughts, books, tutorials, etc. on how to use Jira/GreenHopper to solve the above issues.
A lot has to do with how you set the tool up. Jira only allows one level of sub-task, so you'll have to make the Task type a sub-task type. That will allow you to associate the sub-task to the Story. When I had Jira/GreenHopper on a project in the past, there were a lot of manual steps that I had to take to get it set up--but it was exactly the way I wanted. The installation is a lot easier now, but you lose some of that insight from doing the configuration yourself. Check out the following guides to get things customized the way you want:
http://confluence.atlassian.com/display/GH/GreenHopper+101
http://confluence.atlassian.com/display/GH/Specifying+your+Project+Templates
http://confluence.atlassian.com/display/GH/Setting+Up+Epics+for+your+Project
I wish I could do better than this. Jira is very configurable, and their online help is usually pretty responsive in my experience.
In addition to what Berin notes, stories can be moved to done:
Visually on the task board, by using the Compact task-board mode. (This mode can be turned on through Views: Task Board Modes: Compact(Kanban).)
Via the "Resolve Issue" and "Close Issue" workflow-steps available on the story detail pane.

Resources