Thanks, guys! Any plans to make the sub-task show on the board like they were on classic projects, i.e. not in swimlanes, but below the actual story card and indented? (Or with a placeholder header above the subtask if in a different column as the story)?

Swimlanes cause stories to show as lanes instead of cards which means you can no longer drag them to reorder or move them through the workflow, so I don't like them for that reason. The old classic swimlane-less way of handling sub-tasks was perfect.

Thanks!
Frans

deyanirad the rollout for subtasks is now complete, so you should be able to see it in your instance. Let me know if this is not the case.

Cheers!

please add sub-tasks to our board https://hexinnovlab.atlassian.net

Just tried this and its brilliant - one step closer to being able to move to Next Gen.  It's good that you are already thinking about how to add to the subtasks.  Just need version control now... https://jira.atlassian.com/browse/JSWCLOUD-17260

If I could give Atlassian a big ol' handshake I would. Thanks so much for rolling this out, and I can confirm it works pretty good so far on my next gen projects. You guys rock, and I really appreciate the hard work. I'm sure there were tons of long nights and shattered vacations, so do make sure these engineers, product owners, community engagement folks, all of you guys, get a well deserved break and then some!!

Hi everyone,

thanks for your patience. I'm pleased to announce that Sub-tasks are now available for most customers. 

Please note that we have rolled out subtasks to almost all instances and we are in the process of completing the remainder of the rollout. If you are unable to add the subtask issue type, then don't worry it's coming very soon to your instance.

You can learn more about the feature by reading this blogpost: https://community.atlassian.com/t5/Next-gen-articles/Introducing-subtasks-to-work-breakdown-in-next-gen/ba-p/1105389.

We hope you'll enjoy the feature!

Cheers,

Thanks for the update, Dylan. I had created a custom type sub-task - I presume that won't impact the roll out? I understand I will probably need to delete the custom issue type and but was wondering it would conflict in any way. Should I delete this custom issue type?

Sub tasks seems exactly what we need. Is there anyway to enable these for our instance?

Is this available in early release for cloud?

Really looking forward to the sub-tasks. I would like to use them to make sure UI, BackEnd and QA are all part of the same user story. So a nice self-contained unit.  

At the moment I have had to create a sub-task ticket type and link to the stories.  Not great and it's cluttering up the board.

@Carla Morreale

Tasks in Jira are not children of Stories per se, although if you really wanted to consider them that you could using relations. True subtasks are bound to a story and do not appears as separate tickets in the scrum board, as they are meant to be self contained. In Next Gen, they just aren't available yet, much to our chagrin. Once available, and if that's your plan for requirement structure, then yeah you'd go with subtasks more than likely

@Michael Lawson...Yes–I am an Agile Coach so familiar with these terms and that's exactly how we do it... I was just trying to figure out what using Subtasks vs Tasks buys us in Jira Next Gen.  Are Tasks not children to the Stories? In the past when I have used Jira, that's how it was...but it seems from some of the above comments, that in Next Gen, it is the Subtasks that are the children of the Stories (and that Tasks are in the same level of the hierarchy as Stories). If that's the case we may need to change our hierarchy to Epics-->Stories–>Subtasks (and forego the use of tasks altogether).   

@Carla Morreale

Happy to help!

In many ways, people can use Jira for whatever works best for their organization, so I'm just giving a recommended usage.

I noticed you said you use stories for a piece of a feature, then several stories for the whole feature. This is actually something that comes out in the sprint planning process (if you're familiar with that agile term) whereby stories are assigned complexity. If a story's complexity is considered too high based on whatever relative standards your team sets, it's usually broken down in to smaller stories. Again, though, that depends on how you all want to do things, it's just my own personal recommendation

@Michael Lawson and @Josh Thompson...thanks for your speedy replies!  I guess I have always used Tasks (which can be generated within a story and be a child to a story) as Subtasks. Epics used as a container or category for a large feature. Stories as a discreet piece of a feature (Multiple stories added together give you the complete feature). And Tasks as the activities the Team needs to execute on to complete a Story.  These could be Development Tasks, QA Tasks, UX Tasks...and Bugs for defects on the story that need to be addressed. I still don't see what the Subtask busy me...

@Josh Thompson

In response to the workarounds mentioned, I know I was one who proposed it. One thing I mentioned is that it's basically for tracking only and is not a true replacement, so I want to make that clear to anyone reading. It's a pseudo subtask if you will

From a Jira-functionality perspective (not from a project-management methodology perspective), there are two issue types: Standard and Sub-Task. Each has an associated functionality set. Sub-tasks, for example, can only be generated as child to another Standard task. While Epics can contain Standard issues as well as Sub-Task issues, Standard issues can only contain sub-tasks (or linked issues; there is a difference). The functionality described by others (using a standard Story and standard Task issue type and linking/manually creating relationships) is not the same functionality as is associated with a Standard issue and a Sub-Task issue, though through a bunch of additional effort, you can get pretty close (but why do additional effort when you can just use a Sub-task). Traditionally, I've always taken an Epic --> Story --> Task --> Sub-Task oriented approach, as this tends to provide enough granularity for my projects' needs. However, the Epics and Stories just tend to be documentation/organization containers, with no real functionality needs (though one can make an argument for Epics) otherwise. Sub-tasks within Jira tend to have workflow actions that can be associated (e.g. The parent issue can't be completed until all Sub-tasks are completed), and generally are treated somewhat uniquely in the UI (e.g. "Subtasks" section within an issue; similar to the "## Issues in this epic" section within an Epic; note that this is different from the "Linked issues" section). All the previously discussed approaches (manually configured and related Standard issues) do is cobble together a functionality that is similar to what is typically delivered as out-of-the-box functionality of Sub-Tasks.

Hi @Carla Morreale

Excellent question!!

So I'm not sure if it made sense in my above comment, but the easiest way to view it is

tasks: one off items that don't fit in a story, like a small change to some text, a very specific one off chagne to a button, stuff that doesn't fit in a user/stakeholder requirement

sub tasks: the dev internal tasks that a dev will commit to as part of a story. Ideally these are only for the devs themselves, but it depends on your organization (agile is flexible like that). The technical benefits in Jira are usually related to the fact that subtasks can bubble up information to stories, such as time, other changes, etc. Without some plugins I don't even know about, other issue types will not do this, and I've never found a way to simulate it, hence this entire ticket

let me know if you need any more info!

At my work we use subtasks for bugs found by the QA team related to the task.

@ Andrew Knight and @Michael Lawson

I think I am experiencing the same confusion as Andrew.  Having used Jira for many years, I have always used the hierarch of: Epic-->Story–>Task.  Tasks are the discreet pieces of work the Dev Team needs to accomplish to meet the Acceptance Criteria of a story. We assign points to stories and, at some companies, we assign hours to Tasks.  So what is the distinction between Tasks and Subtasks?

@Andrew Knight

Beyond just being below another issue type, there are other benefits as well, such as time tracking bubbling up to the parent story. Dev might not care, but your PMs and Scrum masters will love you forever. Additionally, you don't pollute your scrum boards (or kanban if you feel like it) with extra tasks, it's all built in. Yeah you could alter the filter a bit to not display them, but it's just not the same, those tasks will be hard to find if someone goes with my work around and not relates the "sub tasks" correctly. Subtasks are fully contained within the context of a story, and rightfully so. Those tasks should describe what the person working on the story is going to do, which is a win all around. It helps a dev stay focused, while at the same time giving other members of the team a birds eye view, not to mention others devs being able to look in and also get a good idea of what's going on and if they can offer any insights. With just a task this isn't quite as useful, or even feasible.

One way to view a task is an individiaul piece of functionality that doesn't really consitute a story, like "change this icon to this" or "nudge this element up a few pixels", your one off items. A story is a total requirement, such as "As an User, I would like to be able to add other users to the application" <- there's a lot that goes in to that, and that's where your story with subtasks comes in.

I hope that helps, although feel free to ask me any other questions that might be more specific

Subtask means it's a Task below another issue type (Like a story/task).

@Michael Lawson

So for my own understanding what's the difference between a "sub-task" and a normal "task" aside from the name. You say Stories are broken down into smaller chunks called Sub-Tasks, and I said that Stories are broken down into smaller chunks called "Tasks".

I'm relatively new to this, and would love some help in understanding the difference (functionality wise or whatever).

And surely Sub-Task by the very nature of the name has to be under a Task (not a story)?

Can I be added to the beta?

@Andrew Knight

I believe this was touched on already, but your solution doesn't follow any agile scrum principles at all, whereas subtasks fit perfectly. It defeats the purpose. Stories are intended to be broken down in to smaller chunks of work, ie subtasks. Those subtasks are really for the developers (or even QA) to manage work for that story. A story has semantic meaning, as does an epic. While it's true you could just change the issue type name if you really wanted, perhaps making a custom one, it's a bandaid. If you'd like to go with a solution like that, here is what I recommend and have implemented successfully without actual subtasks;

• create an issue type called subtask
• the workflow for subtasks is simple, just start, in progress, dev complete, as these are only useful for internal development and not QA who tests and verifies the story along with product owners. It really has no bearing on story completion
• These subtasks are technically just regular tasks within Jira, however you apply a little governance to these tasks and set them as "blocks" relations to the story. This isn't perfect, but it's a good simulation of the idea. There's extra management there on behalf of leads, scrum masters, and project managers, but it helps with organization.

I recommend others try the same

@Atlassian themselves: I'm going to +1 previous asked questions regards updates on the actual implementation and not this testing measure. It's been delayed quite a while now and I think your devs need a break

Hi @jfemia,

I've sent you an email requesting to be added to the early users list of the Subtask feature.

Could you reply me once this feature has been added plz?

We really need it.

Nacho

@jason.s I'm trying to figure out the same thing. Following what @andrew.knight said, there is no Epic issue type available to add to the next-gen Projects, only Bug Task and Story. The other issue types are exclusive to legacy schemes & workflows. Subtasks have been a staple of Jira for years and now all of a sudden they're gone.

I REALLY hate this new system and wish they didn't use their production cloud users as alpha testers.

@pcarver – we've been using sub-tasks successfully since beta opened. functionality is on par with previous sub-tasks in classic. We would love to see the ability to have them stay under their parent tasks and not necessarily take up a swim lane for them but functionally have had no issues.

@andrew.knight – I'm not exactly following you. Stories + Tasks were possible in classic scrum as well. In either instance there is no added hierarchy as both 'issue types' are seen on the same level? If anyone is following traditional scrum approach each has different semantic meaning: Stories are our client deliverable impacting issues, Tasks are internal behind the scenes issues.

If it helps, we found that the Sub-Task issue type was only needed because of the way we were used to using Jira.

In classic projects, we used Tasks and Sub-Tasks, but in Next-Gen we're using Stories and Tasks. It's much the same as far as we can tell.

Stories are the minor goals we're looking at achieving, and the tasks are what makes them up. If you need Sub-Tasks, your stories should be epics, or you have a system to big and complicated to be using the light weight Next-Gen projects.

I don't think Atlassian explained this particularly well.

Hi @jfemia, We would also love to use the sub-task feature. I have sent you some emails with this request too the past weeks, but haven't heard back. Also it has been a while ago since your last - very positive - update in this channel. No problem, I can imagine implementing this feature causes some issues form time to time. But maybe you can provide an update about the sub task progress so it is clear what to expect? Thank you!

How is the roll-out going? From the comments it appears that it began on April 30th, so tomorrow will mark two weeks. Are the results positive? I did NOT request to be added to the early evaluation, but will be eager to see it officially deployed if the beta testers don't find problems with it.

@jfemia
If still possible, we'd also love to participate in the early access for the subtask feature
Cheers

@jfemia We would also like sub-tasks early access if possible. Thanks!

@jfemia We are also interested in testing subtask feature. Thanks!

I would like sub-tasks enabled for my next-gen project! Thank you.

@jfemia we would like to get early access to subtasks as well, hfnswedenab.atlassian.net. Thank you

Please could we have subtasks enabled as well, limejump.atlassian.net. Thanks

@jfemia, a great improvement in the value offered by this feature is the ability to have the subtask estimate be added to the parent ticket's estimate (mentioned by someone in my company when I announced the enablement of the experimental feature as a reason for them to opt-out of using this feature).

Also, in the introductory email it would probably be useful to mention that the button is added to the shortcuts under the ticket name and that it is called "Add a child issue" - took me a good 5 minutes to find it (via comparison with a project that did not have this enabled).

@jfemia I'm also interested in testing subtask feature. Thanks!

@jfemia we'd like an early access as well - thanks!

can we participate in early access for the subtask feature?

Hey @Gerard,

Would love to participate in early access subtasks evaluation.

Thanks!

Pavel

Hi @jfemia,

Sent you an email requesting to be added to the early users list of the Subtask feature.

Thanks in advance,

Ger

If you are still taking candidates to the early users list for the subtasks feature we would also like to be added.

Thank you

Hi, we're using also for couple of project already next-gen and struggle with the missing sub-task feature. Would be great to be one of the early users to test it.

Hi, we're also using next gen project and hit this problem - can I request addition to the early users list for sub tasks @jfemia ? Thanks, would greatly appreciate it!

If you are still taking candidates, we would also like to be added to the early users list for subtasks. Thanks @jfemia

Hey @jfemia, just sent you an email to be added to the early users list, thanks for the constant updates !

Hey @jfemia, can we have subtasks enabled in our instance please??

Thank  you

Hi @eryan

I wonder how challenging Jira's refactoring should be, but your work is being very good.

In a pessimistic view, can you give a prediction of when this feature will be available?
We are looking forward to starting a new next-generation project and the lack of this feature is the only reason we have not started yet.

We have tasks enabled now too. Thanks for the tip Erika on 'Group by: Subtask' on the Board, but being part way through a project with some things set up as tasks 'related to' the parent story and some set up as proper child sub-tasks is proving a nightmare - and the ability to convert task types isn't available yet.

I like the new child sub-tasks - much better grouping under the story, but the story points estimate isn't shown on the Backlog, or rolled up to Story level, you can't filter sub-tasks by Assignee on the Board - which is how we run our daily scrums, and they don't show up properly in reports based on Sprint. And I can't get a Workload gadget working on my dashboard (breaking down by Story Points and Assignee).

Wish I'd never started this project using Next Gen now  

Hey @jfemia, could subtasks be enabled for our instance please?

Very much looking forward to trying it out.

Thanks!

Thank you Erika!

Subtasks are showing up on our Next Gen board.  You need to select Group by:  Subtask

How about the ability to see these subtasks on the board?

Our board has gone after enablind subtasks.

adam.dowsett / d.cherepanov Thanks a lot for the feedback. 

Adam, another way to achieve what you're asking is to use the "group by subtasks" feature. Once you're in this mode, if you select the assignee in the filter bar and start using the inline issue create to create subtasks, you will see that the subtasks will be automatically assigned to the person you've selected in the filter.

Dzmitry, this is definitely on our radar but I can't give you any time estimation unfortunately.

chris154 I'm sorry about the wait, we're going through the list of people requesting the feature as fast as possible. You should have it enabled now, enjoy the new experience!

Hey Julien,

What's happening?

I've sent you a couple of emails and replied to Eoin's email a few weeks back and still haven't heard anything from you.

Just a tad disappointed about that.