View, rank and assign sub-tasks to sprints in Greenhopper rapid board planning mode

[Tim Pokorny]

To break work down into managable tasks while retaining a nice and clean link back to the overarching story, we use sub-tasks. For the life of me, I can't figure out how to view, rank or otherwise assign those sub-tasks to a sprint individually.

After trawling these boards and seeing a cascade of similar compliants I am trying to determine a few things:

• Is it intentional that sub-tasks cannot be used with the new rapid boards?
• Is this ever going to be changed?
  • If not, is it Scrum idelology or some underlying design limitation (I really hope it's the latter)

More details about what we do

The problem I have now is that the only way to solve this problem is to have the all my sub-tasks appear as major tasks. This causes a couple of issues.

Firstly, there is no nice clean way to link them to their parent as core parts of the same overall task.

Secondly, as a matter of policy we force people to record story descriptions according to a certain template. This helps ensure the high-quality of stories and helps properly categorise them as stories. Basically, we only allow people to register issues of Epics, Stories or Defects. From here, we break the story down into a bunch of small tasks (similar story to many) which may be of various differnet types (New Feature, Improvement, Documentation Task, etc...). This puts a real organisational distinction between what is requirements (Stories) and what is implementation (everything else) and overall results in a higher quality of reporting and a simpler process for everyone.

If I have to move all sub-tasks to regular tasks so that I can do crazy things like assign them to sprints, I'll have to make it possible for all the various types to be registered. The only way from then on to keep this policy is to enforce it with a big stick, which is fine and all, but creates a lot more work.

I'm fine with this if it's just an internal technical limitation. I can understand that and live with it, but if it's because I'm not doing "Atlassian-certified" Scrum... Well, I get a little frustrated then, so I'm just trying to figure out where it all stands and what the likihood is that it'll ever get changed.

The sad part is, if rapid boards didn't look so awesome I wouldn't care.

[Alexander Bibighaus · Accepted solution]

It is totally uncool that sub-tasks can't be put into iterations due to idealogy. It is enough for me to not use the tool b/c I can't organize things how I want.

[Bob Allan]

+1 for feature to enable subtasks as work in Jira Agile.

People manage projects using WBS (tasks, subtasks). No subtask in JIRA Agile means JIRA Agile not good for managing a project. It isn't any more complicated than that. Work-arounds, are, well, work-arounds (Epics, Stories, links, etc.).

[Arik Zochtolovich]

I agree with Tim here - we would love to use sub-tasks to break down a specific story into, well, sub-tasks :)

It makes perfect sense for us here - for example, suppose we have a story called "Implement Big Bang Theory": we would like to break this down to:

• Sub task for our product manager to properly define the requirement (spring 1)
• Sub task for one of our team leaders to prepare a a technical design (still in sprint 1)
• Sub task for our IT guy to prepare our servers for larger scale (spring 2)
• Sub task for our developers to implement the technical design (also in spring 2)

One can argue that this is in fact an Epic - but the problem is, we have 100+ of these concurrently at any given time, which won't work well with the current Epic UX... sub tasks seemed to us the perfect balance... until we saw they won't show up in the rapid board :(

[steve laflen]

+1 on this being un-cool. I can't use the new rapidboards until this changes. They finally added the versions to the rapidboards and i had hope but I need the team to be able to view sub-tasks. Until then, I'm stuck in classic mode and so is my team. -Steve L Coupons.com

Come on Atlassian, open up the settings.

[Yann Augustin]

Hello,

I agree with Arik and team.

Our development team needs validation from governances before we can start coding. The architect/development team is first making solution and technical design to be submitted to the governances. So regarding the development team one story is composed of 3 sub steps, Solution design, technical design and development. We often need to plan the 3 steps across different sprint.

We use one main issue with 3 sub tasks to correctly follow the lifecycle of one story.

Using normal issue with link makes more difficult to follow the story. Time management on main issue includes subtasks when normal link does not. Furthermore we are using link to…link issue. For example if they are related or duplicate stories.

Using Epic to split a story in sub steps will makes the real usage of Epic unviable. We need Epic to group different story together as a bigger level. Not in term of step but as big picture of different story.

I’m a not an expert in Scum, but having Greenhopper not managing subtask in plan mode, makes us to not be able to use it. This is really frustrating as we love the way it ease the management of the team. We are now making all the planning manually without the possibility to make real statistics that Greenhopper provides.

And I do not see any other way than subtasks to use Jira with our workflow constraint.

[dmitry b]

I feel like this limitation isn't due to the ideology but rather due to the lack of understanding of the methodology.  Short users stories are not the only entities that can comprise a sprint.  It's perfectly acceptable to have time-boxed tasks like spikes, for example.  You have a user story that you can't estimate because it has unknowns, so you schedule a 2 hour spike into a sprint.  Or you have a bug report.   You can't just schedule a bug into a sprint because it has too many unknowns.  First a bug needs to be reproduced, which is a  time-boxed activity.  Second RCA needs to be performed.  A time-boxed activity again.  Finally, the bug itself is getting fixed.  Sub-task designations are perfect for time-boxed activities.

[Tim Pokorny]

G'day guys. I've just given up here and assimilated.

The recent updates to Jira and Greenhopper have taken away much of the pain. There is now an easy way to drag/drop issues onto Epic's to form the association, and with Epic's listing their associated issues in the same way tasks/subtasks did before, and individual issues showing badges of the Epic they are linked to, most of my complaint starts to disappear. So all in all, with the current state the number of complaints I have are now limited to smaller things. I'm going to close this off as answered so that I stop getting email reminders for me to do so, but I do hope that the later versions of Jira/Greenhopper are also yielding similar stories of lessened issues for other people as well.

[Michal]

So you just use Epics instead of Stories to store sub-tasks across Sprints then ?

I was thinking about that but that means there needs to be a Super-Epic too which there isn't.

[Tim Pokorny]

G'day Michal, We use Stories as the unit of work (anywhere from one hour to a few days) and then use Epics to wrap up strories across sprints. To get a more coordinated picutre of where we are heading at a higher level, everything is assigned to a particular upcoming release version and that pretty much covers all we need. Release planning through to longer "cross-sprint" tasks and down to the individual work unit level.

[John Garcia]

Maybe if you used regular Issues instead of Subtasks, that would resolve the problem? Then they can be ranked regardless of linkage.

[Tim Pokorny]

G'day John,

That's what we'll have to do, but unfortunately it breaks the strong association between the tasks and thier driving story (links just aren't the same) and means that I'll have to update the statuses so that all the different technical task types are available as top level tasks. I'd previously restircted this down to Epic, Story and Defect, and provided nice cut/paste templates for people to use when registering these (gives some consistency and raises the quality of reporting). The lack of being able to register tickets of any other type greatly assists in driving conformance to the development process, taking away the need to chase people with a big stick, which is fine, just time consuming and ultimately, perhaps more pain than just living without the boards.

[Nicolas Bourdeau - 103]

The ranking of sub-tasks across parents is not available in "work" mode.

[Renjith Pillai]

I don't expect this to change as the design is based on the fact that a story is planned as a whole in a sprint. If not, the size of the story is too big which calls for a change in the way the backlog is groomed into stories.

See Shaun's comments in this thread.

https://answers.atlassian.com/questions/85897/how-do-you-plan-subtasks-into-separate-sprints

[Tim Pokorny]

G'day Renjith,

I've seen Shaun's comments and unfortunately they don't give me much hope. I guess the real problem here is the misunderstanding that a User Story is an entire, atomic work unit.

It's not just a matter of needing to break things down into further stories because one is too big, but rather, it's a matter of needing to break a story down into its different sub-components which may have different priorities and even different assignees. The completion of a story as the overall driver for "work" might include a bug that needs to be fixed, and an additional improvement to some comopnent, some documentation updates and an addition to our QA test suite. Each of these tasks only make sense in the context of the driving story and each may have a different level of priority. The use of Sub-tasks is not always a matter of size, it's a matter of compsition.

It's the assertion that I *must* have stories that are too big and thus I'm "doing Scrum wrong" that gets me going a bit. That's the idelology bit that's preventing me from being able to use the tool and that's why I'd be disappointed if it were the case.

[Renjith Pillai]

I understand.

Ranking is still possible acros sub-tasks while in work mode, but planning is always common (same sprint). While I agree completely with your statement here "The completion of a story as the overall driver for "work" might include a bug that needs to be fixed, and an additional improvement to some comopnent, some documentation updates and an addition to our QA test suite." , they having different priorities is somewhat unacceptable to me.

This means that these tasks are being done by different teams, am I right? Or members of the same team? If members of the same team, it looks quite disturbing to me that they have different prioties. Scrum makes a basic assumption that the teamed is united in terms of the Sprint goals and they do what is needed to push our or complete the most important story in their list.

If they are being done by different teams, Tim, it is high time to think about getting them together. Once you see the speed at which the story gets finished when they are in the same team, you will be thrilled.

[Tim Pokorny]

G'day,

They're not being done by different teams, but we will slip certain tasks to batch them together for efficiency (a few orgainisational things we have to deal with). That's beautiful idelogoly, but the process we have works well. The tool however does not work well for that process and the only thing preventing it is the inability to view sub-tasks as standalone items in the plan view, which feels kind of arbitray, but whether or not it is or there is something technically deeper at work is what I'm really wanting to know. If it is idelogoy then that's cool as well. Sad, but it does save me some money as I drop back to just using vanilla Jira.

[Nicolas Bourdeau - 103]

+1 for this. We are also using sub-tasks and it is a major blocker for using Greenhopper new boards!