nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Planning sprint in greenhopper 6 with Scrum board no subtasks shown

Bjarne.Sehested

Is there any possible way to display subasks to stories or tasks in the "Scrum plan Board view"?

Our company operates with storyes that can be spread over more than one Sprint, subtasks/tech.tasks are dedicated to sprints. so when planning we dragged the subtasks to the sprint. this is a huge problem for us if this option is not available in greenhopper 6

any ideas?

Accepted answers

Gregory Demotch

This is a major problem.

There should be an option to say include subtasks yes / no.

When it comes to planning, subtasks are by far the most useful mechanism for planning / logging hours. Different subtasks could be executed by different people in different iterations/sprints and sometimes on different platforms (yet all are part of the same story).

Proposing to see them as stories is a ridiculous workaround and not answering the need for planning. With subtasks you can cumulate time easily for the parent by logging the time for the children subtasks/tech tasks. We need to be able to say that a subtask can be planned and executed in different sprints.

and hey, they whole point is that Jira and GreenHopper need to be a flexible a solution.

From what I've seen so far GreenHopper, while certainly offers cool advantages, is one of the most rigid, inflexible solution and I'm feeling like you guys are boxing us into YOUR own ALM vision which arranges neatly YOUR own development logic.

Can you please stop developing a singleminded solution and then try teach us about how we should use Project Management properly, but start focusing on flexibility so we can apply our Project Management Reality (which in many cases we do not have 100 % total control over and some of it is inherited and imposed on us ? )

All comments

unknown

Do you mean the sub-taks are nowhere to be seen - because they should be visible under sub-task-tab on the right when highlighting a story - or do you want to have them visible directly under their stories/tasks like on classic boards?

If it's the second, this is not possible yet. I would like to refference here: https://confluence.atlassian.com/display/GH/Using+Plan+Mode, as they raised several issues about this and other problems or feature wishes.

Bjarne.Sehested

Hi Carsten Thanks for your reply, my question might have been a litle unclear, my problem is the second as we have storyes that span over more than one Sprint. subtasks/technical tasks are the ones we assign for a sprint in the planning mode and therefor the new board types are not useable for us.

I guess we'll have to use the classic board until this feature is enablet any idea when?

sclowes

Hi Bjarne,

We have no plans to enable sub tasks to be planned in to sprints separate from their parent story. Scrum is pretty clear that stories offer user value, so they are the unit of delivery, sub-tasks are just a way to break down the technical work needed to deliver the story.

If your sub tasks are sufficiently large to deliver customer value you might like to convert them to stories and link them together. Alternatively you could create an Epic, convert your sub tasks to stories then link them to the Epic.

Thanks,
Shaun

sclowes

Hi Tim

There's no problem with having sub tasks of a story assigned to different people. If a task doesn't get completed in the sprint (and the story is therefore incomplete) just let the story automatically go back to the backlog when the sprint finished and drag it in the to the next sprint.

Thanks,
Shaun

Ari Brown

Hi Shaun,

I totally understand where you guys are coming from here and I get it in an Agile sense - you shouldn't necessarily NEED to see the subtasks in planning mode because planning deals generally with stories, not with sub-tasks, but knowing what is there is very valuable to us and I'd love to be able to see a threaded view (like the work board) instead of needing to click each story and see the subtasks in the tab on the right. Consider it a feature request as everyone here has independantly reached the same conclusion and it would be really nice to have.

Joseph Narai

The issue for us is we use Tasks and Sub-Tasks to plan a project with a simple one layer task/sub-task structure (using the Gantt Chart Project plug-in)... and then when we go to execute the project, we can't put the Sub Tasks onto the agile board.

Not being able to add Sub Tasks to the sprint, means we need to either change the way we plan our projects in JIRA, or once planned, we need to then convert all the sub tasks to tasks, when then breaks the Gantt style project tracking...

I know agile is not supposed to conform to gantt style practice, but we use a combination, and I'm sure we can't be alone...

Jean Resener

Hi there,

This is to pile onto this question, but from a different angle. The sub-tasks are not inheriting the Epic Link of the parent issue. So when we attempt to pull a report to see all issues tied to an epic, those are missing. This is okay from a "a sub-task doesn't deliver business value so don't show it" viewpoint, but it's NOT okay from a "we do timesheet reporting based on the EPIC the issue belongs to", and now we have sub-tasks completely orphaned from the time tracking to Epic rollup process.

NO BUENO!

Jeremy Glazman2

The biggest problem with not showing subtasks on the main Plan view is that it completely hides tasks from users. For instance, if I create a task (assigned to me) and then add subtasks to it (assigned to others), those other users will see zero tasks when they use the "Only My Issues" filter, which is not very helpful.

Those tasks reappear in the Work view after the sprint has been started, but this kind of defeats the purpose of plan mode if users can't plan their work before a sprint begins.

Gregory Demotch

This is a major problem.

There should be an option to say include subtasks yes / no.

and hey, they whole point is that Jira and GreenHopper need to be a flexible a solution.

Jeff Orenzow

Not sure if this is a viable solution but I've just had "Task" (not be confused with Technical Tasks used in Sub Issues) added as an issue type and will be linking "Tasks" to Stories so that they can be included in the sprints. As a new user to Jira / Greenhopper I had the same complaint as above with sub tasks and do not want to use the classic version so hoping this modification addresses the limitation. The only drawback I can see presently is that the linking must be performed after the issue is created. An extra step added where the create sub task was available directly within the story itself.

Hope this works and can be a solution to anyonce else experiencing this same issue with planning sprints.

Klas Färd

Hi,

I can see the point of Tasks/sub-task vs Epic/stories but since sub-tasks are very easily supported by Jira why not use them !? Even if they aer called tasks - I can still use them as stories.

Even when creating an Epic i get a quick-link for creating sub-tasks and I can list them easily in a context etc, but they do not show up in the agile planning board - very annoying !

I dont really buy the argument that "sub tasks" should not be used.
First of all reality is always present, thus an ideal world is an utopia and most of us need to live with taking small steps at a time, and using Jira/Agile addition even in the real world would be nice. Second, being a developer since 10 years, I sort of recognize the pattern in fitting a hard-to-implement-missing-function as "this is how it should work"

I can switch to Epic/stories sure - but then give me the same support as with tasks/subtasks when it comes to creating, linking them etc in the rest of the tool...

Jeremy Glazman2

Sub-tasks are awesome during the sprint, we really like how the Work view organizes them and makes it clear what the progress of a feature is and who is responsible for it. We just can't think of a reason why they wouldn't appear in the Plan view.

Maybe the expected use of sub-tasks is to not give them time estimates, but to instead only estimate the parent task? That's kind of silly though. Putting an estimate on a task that has subtasks doesn't really make any sense.

What would be great is if the parent task would just show its estimated time as the combined estimates of all of its subtasks.

Peter Denniston

I'm not buying the argument that not showing subtasks in the Planning mode of a rapid board is "by design". It works fine in JIRA OnDemand, it just doesn't work in the downloadable version of JIRA.

Craig Connell

The other disconnect here is that you can have Epics, which can have subtasks that are User Stories (User Story). I can then configure the system to allow the type "User Story" to be associated with points. My epic might be too big to get in a single sprint, but my user stories, which are part of this epic (sub portions of it as far as I am concerned) should in fact fit. So now I have an Epic that contains User Stories, but I can't actually view those user stories in my plan mode. That doesn't make any sense and seems to be a perfectly "acceptable" use of stories within agile.

Jon Madsen1

I would also be able to list subtasks into the plan section of Agile. I have each of my developers working on tasks and subtasks. Since subtasks do not show up in the plan section my developers don't see that subtask to make sure it is done. This needs to be fixed.

Moriah Chandler

Working with support from Arsenale Dataplane, we are now able to view a report that includes epics, the stories in those epics, and the subtasks for those stories. Though we are using Dataplane (a paid addon), the scheme for setting up a scripted field that can be used to "segment by" epics is still useful without it.

How Dataplane solved the problem for me:

Install Scriptrunner addon (free).
Create a new Script Runner custom field ("Scripted Field") in JIRA, called "Master Epic" (or something similar). Here's Arsenale’s own Dataplane primer on how to set up and use Scripted Fields. Here's a more general Script Runner primer on how to use a Scripted Fields. You are going to use this field to report on the Epic that the issue is a part of, regardless of whether the issue is a parent or a sub-task issue. Scripted Fields use programming script written in a language called Groovy. It's virtually identical to Java.
After creating the field, go to the Admin>Addons tab.
Click on “Script Fields” under the Script Runner section on the left.
Click Edit.
Enter the following script:
Reindex JIRA.
If you are using Dataplane, reindex it also.
In Dataplane you can create a report that uses this scripted field to “segment by”.

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.issue.Issue;
 
CustomFieldManager fieldManager = ComponentAccessor.getCustomFieldManager();
CustomField epicLinkField = fieldManager.getCustomFieldObjectByName("Epic Link");
CustomField epicNameField = fieldManager.getCustomFieldObjectByName("Epic Name");

if (issue.isSubTask())
{
    issue = issue.getParentObject();
}

Issue epicIssue = (issue.getIssueTypeObject().getName().equals("Epic")) ? issue : issue.getCustomFieldValue(epicLinkField);

return (epicIssue != null ? epicIssue.getCustomFieldValue(epicNameField) : null);

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software

sub-task