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?
Related
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.
I'm new to Jira so maybe my question is trivial. I need to get a statistics about a whole team and individual members. Currently I'm mostly interested in a mean time a person spends on a task (all our tasks have similar complexity).
How can I get this information in Jira? (Currently we don't arrrange sprints, we just create tasks and assign them to developers.)
On your filters you can show the attribute "Time spent" as column. Click on the top right on "Columns" and search for this attribute to enable it on your filter list.
Furthermore you can add Gadgets to your Dashboards. I see two gadgets here:
Resolution Time
Time Since Chart
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am trying to get my head around how story points are assigned to sub tasks and how the story points are managed in Jira.
I have a user story which we have estimated at 25 points.
A developer will take this user story and split it up in to a number of tasks.
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points? And if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Also, if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
Let's pretend Jira isn't the issue for a moment.
First, tasks should be estimated in hours, not points.
Second, stories should only be counted toward the burn down when they're complete. (https://www.scruminc.com/sprint-burndown-by-hours-or-by-story/)
Third, consider what value you are getting from the tasks. In teams where we have done tasks, I've found the work of creating the tasks a great validator of whether or not the story has been defined well enough. Marking off the tasks has been of less use to my teams.
Fourth, when a story is not complete at the end of the sprint, it should go back into the backlog for the product manager to re-prioritize. It may be that it's no longer a priority (especially if it's taking much longer than expected).
https://pm.stackexchange.com/questions/3990/unfinished-stories-in-a-sprint
From teh scrum guide - "All incomplete
Product Backlog Items are re-estimated and put back on the Product Backlog."
Personally, I don't like to re-estimate because then some effort is "lost". If you don't re-estimate, then your velocity balances out over time, even if each individual sprint velocity bounces up an down.
In some cases, when stories tend to be large, when they are estimated to take more than 4 or 5 days you can easily lose track of progress within a sprint. This is especially true if the sprint is 2 weeks long.
Teams I've worked with have moved away from tasks in favor of smaller stories. (Currently, we use a rule that if it's > 13 story points, it's probably too big and should be split up).
All this considered, Jira should fall in line fairly well.
I find sub-tasks to be the hardest feature to use in conjunction with agile in JIRA. It always ends up being one of two scenarios, reminding why I try to never use sub-tasks to begin with:
Each sub-task is actually a story, and the initial story was way too broad. Every time I'm in this situation, the original story goes over 1 sprint, if not many sprints (causing the developer to rush, shirk, be stressed, etc)
Or, the sub-tasks themselves are too detailed and aren't worth putting in JIRA as their own issues; instead you should just add a comment to describe progress or ruminations to the original issue/story and avoid the JIRA overhead.
EDIT: In response to #DaveHillier
I don't like creating subtasks because it's more JIRA pushups. I think the allure of subtasks is that it makes your use of JIRA appear more structured, but I think an important part of using JIRA well is to keep issue count as low as you can, and yet still be effective for the team. I can't possibly justify this why I think issue count should be low in this thread, other than to say, ' with JIRA, less is more'.
Let me show you what I do that satisfies the following requirements:
transparent progression on the issue (other users can be notified if they want)
lets me organize my own thoughts
remains inline with the issue, letting someone look at my one story and understand quickly where I'm at
I make a list in the description of my main story, using JIRA markup like so:
Build the thing. Lots of words blah blah.
h3. Progress
* code it
* test it
* deploy it
Then using JIRA markup, I can add little green checkmarks as I get done using (/) next to each bullet point, letting any 'listeners' of the bug stay abreast of my progress.
Build the thing. Lots of words blah blah.
h3. Progress
* (/) code it
* (/) test it
* deploy it
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points?
No, tasks of a story are not assigned any points because one completed task will not provide much value to the client / enduser. All the tasks combined will deliver a working piece of code much would be of some value for the enduser. In essence a story is not complete till all of its tasks are done. Remember: Working software is the primary measure of progress.
if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Since task dont have any points (as mentioned above), this becomes obsolete.
if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
If a story remain incomplete at the end of the sprint then you have two options, either move the whole story back to the product backlog or if any part of the incomplete story can be salvaged and treated as a working piece of software then split the story into two. Working part will be considered complete in the current sprint and non-working part will become part of the product backlog. This part will be treated as a new story and it should be estimated as a separate story. You cannot split story points between the working part and non-working part.
Sub tasks don't work well in with Jira Agile.
In my current team we don't use them.
I disagree with sethcall, that there are no reasons that I should be using sub tasks.
I'd like to track that I can't easily at the moment:
tasks for completing each point of a definition of done
tasks to make acceptance tests pass
There are plugins that support acceptance testing, (e.g. Behave for JIRA) however I have no experience of them.
Some have suggested to use custom fields for your definition of done (and acceptance tests), but I'm not keen on that idea as there are too many exceptions to the list.
Here is an article that suggests using checklists for acceptance tests.
Might be worth a try.
To manage the scrum development process of a big community website, we decided to move to JIRA/Greenhopper/Bonfire.
I have created elaborate Epic, Stories and Tasks, all well linked to each other.
I would like to develop the "Product Story" in more detail all the time by adding new Epics, new Stories to (new or existing) Epics, etc.
To be able to do this properly, I want to have a hierarchical overview of all issues: Epics, Stories, Tasks, etc.
Question: How do we set this up in JIRA?
Why?
=> My approach is from the point of view of project management: getting everybody aligned around the same vision. However, I think it is part for everyone in the team -especially for the ones who are actually building the product- to have a quick view of how their current or planned work fits into the big picture.
Stories have sub-tasks, which will be shown hierarchically in the Sprint, but all sub-tasks have to be completed in the sprint of the user story. I also think when you create a story you can specify an epic, which will create a hard-link ( the same as story -> sub-task). Is there a reason you want to use a Jira task? To me it looks that in a SCRUM environment you only need Epics, stories and sub-tasks. Maybe some spikes and support tickets from time to time.
Coming from a tool like Rally, I can appreciate you wanting to see the big picture. We transitioned from Rally to Greenhopper over a year ago mainly because of costs. Lets just say you get what your pay for. I haven't found the feature you're looking for in Greenhopper, it only has a single threaded view for things like Epics to Stories (on the planning page) or Stories to tasks on the (on the work page)
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.