Is there any way to show subtakss on a JIRA Agile planning board? This would be most help when a feature can not be finished in one sprint.
Thanks,Chris
Hello Chris,
Actually, JIRA Agile will not count sub-tasks in. What we advise is to move them up one level. For instance, change issues to epics and sub-tasks to issues. THis way you will be able to manage them in a more feasable way.
If you'd like to take a look at a very detailed answer regarding this matter, please see here:
http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/
Benito Picarelli
+1 This is causing us huge headaches. Seems to be very basic functionality that most users would need.
I am currently in the dilemma of choosing between rearranging my entire task hierarchy, or ditching the agile functionality. I'm trying to get my team to accept JIRA, but every time I run into one of these "Atlassian says no" issues, it becomes harder and harder.
C'mon JIRA, there are enough people out there who want sub-tasks to show up on the board. You can at least allow this as an option.
Subtasks are only ever children of a particular parent Task or Story right?
So when I go to the planning / backlog board, and click on, say, a Story... and look in the right-most panel, I can see subtasks. If subtasks are just details of a Task or a Story, then why do you need to see them on the planning board, if you're planning at the Task or Story level?
If you move a Task or Story into a Sprint, you'd want all those subtasks to follow.... You couldn't leave them behind, right? So it would seem to make no sense at all to see subtasks on the planning board / backlog outside of the Task or Story they're subtasks of.
I think having subtasks on the planning board itself would be problematic because it would allow you to drag a subtask to a sprint without it's context/parent/story/task.
If we are only partially through an item in a Sprint when the Sprint ends, we simply roll that item (Story or Task) into the next sprint. All of the ToDo/InProgress/Done statuses are preserved.
Screenshot_2016-09-28_08_48_16.png
SBY_board_-_Agile_Board_-_JIRA.png
See my above comment about teams of specialists rather than teams of generalists
+1 for having an option to show sub-tasks in the agile planning board
I agree, this is really needed functionality.
I hope they add this in a near future!
+1 We need to see sub-tasks on boards as well. Re-structuring our project hierarchy will be a major pain.
+1 for this.
To accurately plan a sprint based on time estimates (not story points) we need the time estimated per subtask to be included in the overall summary.
What's the point in the summary if it's not including absolutely everything assigned to that user?
+1 for this request.
+1, please allow full functionality for sub-tasks
(my sprint planning takes user stories and breaks it down into subtasks, if after the breakout of work we realize it's too much we may push it to another sprint and split the User Story... without full visablity to the work involved working in JIRA is a nightmare)
Agree with this option. Nice feature for visibility to the agile board.
I can't believe this is still an issue. It's been a painpoint since we started using JIRA over half a decade ago. Listen to your customers, Atlassian. Make it an optional feature. It's obviously in demand.
I would love personally to see this at least as an optional setting. Default off, just option for people that want to see it can see it.
I am in a comparable situation as Aaron Sua. I have a team, which shall do "end to end" development, meaning, we have to implement backend logic, Client Interfacing implementation and three different types of client architectures: iOS, Android & Web. Therefore my team is a set of specialists and not of generalists.
We have to split a userstory into subtasks for backend, testautomation and a set of clients. Sometimes even conceptual subtasks are needed.
What I observe is a general tendency to ignore the complexity of the subtasks, because they are not explicitly estimated. So adding storypoints to subtasks and adding them up in the umbrella task, would be a great help for us.
Currently we are only estimating the surrounding umbrella task. Besides, that it is underestimated, it often happens, that not all subtasks are finished within a sprint. We have a definition of done in the organization, that a task is only finished if all subtasks are finished including testautomation. Because we have no way to account the finished subtasks to a sprint, we run into the funny situation, that the surrounding umbrella tasks is not accounted to the current sprint. Then in the next sprint it gets reestimated, since some subtasks are already done. It suddenly becomes "cheaper". So when the surrounding tasks gets finsihed it appears with much less storypoints than the actual sum it has had over lets says two sprints.
Long story told short: We need storypoints within subtasks to get a proper planning in our organization. We are less focussed on tracking, since nobody is consuming this data. But we want to become more reliable with our planning.
Dear Atlassian, please listen to your customer and be less focussed on the way you are convinced others should work...
I am really wondering why there is no reaction by Alassian product management to all the request here in this thread.
+1 for this;
We are use subtasks under a primary in order to group relatively small work packages (approximately 5 items for each group), the group is managed as a bundle, but individual subtasks are executed by different individuals and have significantly different lead times and state blockers.
Not being able to visualize these sub tasks in a scrum board is a notable issue.
+1
Please do this. We all want it.
Though not available on scrum boards, it may be helpful to some to know that subtasks are available on kanban boards. In the below shot, you can see task LVWB-12, and its two subtasks, LVWB-13 and 15, underneath it. Again, this isn't going to satisfy those needing subs in a scrum board, but for some projects it will help.
Joining the chorus here, it's beyond me why Atlassian, with all the flexibility they do offer, won't allow subtasks to be posted to scrum boards. This position forces users into painful (at best) and impossible (at worst) scenarios, requiring complete reconfiguration of all subs to tasks, tasks to stories, and stories to epics, and even epics into Projects (?). This is actually a pretty serious flaw in their featureset.
https://confluence.atlassian.com/jirakb/how-to-display-sub-task-below-the-parent-task-in-the-backlog-779158697.html
I can see subtasks as cards on my boards. Am I missing something?
Board Settings > Swimlanes > Base Swimlanes on Stories!
people wants to display the sub-tasks in the backlog, not in the sprint boards
I've tried this, but the initial problem remains. There are no sub-tasks in the backlog. Not the order is wrong, but they simply are not shown.
I just use a filter for the project, ordered by rank asc.
How did you get your sub-tasks into the Scrum backlog in first place?
+1 Please add sub-tasks to the Backlog view under their tasks.
We are running v7.4.0 and the Kanban Backlog provides the feature of showing the subtasks. But then, this version is not yet providing Epics for Kanban. So you can choose
-> sub-tasks -> Kanban
-> Epics -> Scrum
But as far as I have read, they are on it to provide the Epics for Kanban. Don't know what the plan is for the Scrum Board.
Upgrade to 7.5 and you'll have epics on kanban
hi. Oh wow, that was fast. Haven't watched the feature development for 4 weeks and swoosh it's there. Thanks for the information!
We have no flexibility in how we use epics because of organizational constraints. Please let us see subtasks. It really isn't much to ask. Make it an option if you have to so purists don't have to have their sensibilities offended.
I have come to the conclusion that Atlassian is being deliberately pedantic about the whole Epic/Story/Subtask thing, and the "Scrum Masters" of the world are desperately trying to shoehorn explanations into why this is a good idea. I think its a case where common sense is being over-ridden by pedantic definitions and rigid adherence to Scrum theory, which, ironically, is the opposite of what Scrum is meant for.
Our team has simply given up on sub-tasks, and we don't use the feature at all.
This addresses all our needs, and gives us all the flexibility we desire. It also allows us to not get caught up in whatever bull**** definition Atlassian may have for different ticket types. We use them as it makes sense to us.
Is there any solution to this still ?
It looks like you're new here. Sign in or register to get started.
