When should you create a subtask?

[Ramon Padilla]

When should you create a subtask? It seems like a simple question but I can't find the answer anywhere. Should it be before the sprint starts or after it's started?

Note the following if the subtask is created before the sprint starts:

1) Subtasks are NOT visible on the product backlog.

2) Subtask estimates are NOT not included in the total 'Estimate' field for all issues on the product backlog.

3) Subtask estimates ARE included in the 'Remaining' estimate field for all issues on the product backlog.

4) When filtering on a user, the total 'Remaining' includes the remaining estimate of a subtask if the parent task is assigned to that user, even if the subtask is assigned to a different user.

If a subtask is created once the sprint starts, doesn't that affect sprint scope?

[Nic Brough -Adaptavist- · Accepted solution]

In plain JIRA, a sub-task is for breaking up an issue (note - not a "story" - plain JIRA is not really very "Agile"), into pieces that can be tackled separately.  The best reasons for doing that are that there are distinct pieces you want to track separately, or pieces with different data sets (components or due dates for example) or that you want to give pieces of work to different people, or you want to estimate the pieces separately because the main bit is too large, or, or, or, etc etc etc.  Sub tasks are their own pieces of work in their own right, and the parent link is not actually vastly important.

In Agile though, sub-tasks are very much part of their parent.  If you install Agile/Software and look at the defaults, you will find that sub-tasks do not have estimates - all the work is done at the parent level.  Sub-tasks are totally subordinate to their parents, and are not really useful for anything other then letting developers hack a story into bits to simplyify their approach or assign different bits of it to people.

In short, until JIRA Software improves the handling of sub-tasks so that you can estimate on them... don't.  Create them as you need them to break up work, log time against them, yes, but do not estimate sub-tasks.  The discrepancies in behaviour you are seeing with subtask estimates rolling up to their parents (your points 3 and 4) are because plain JIRA Core is doing what it's supposed to, but the Agile part of it doesn't care about that (points 1 and 2).  I don't think sub-tasks will ever be part of the backlog because they are subordinate to their parents, and move with them (it's nonsense to prioritise a sub-task outside it's sibling group), but the estimates in Agile don't really work.

[Alex Mukha]

Hi, Ramon!
How you fixed problem with sub-task estimation? 

[Mark Biro]

Hi KSL,

Plangle gives you the opportunity to see your subtasks in the "Backlog".

More precisely: Plangle is backlog-like issue editor that works like Excel.
And it allows you to see your subtasks.

Like this: 

Find it on the Marketplace: https://marketplace.atlassian.com/plugins/com.moresimp.plangle
Or try it without installation: http://demo.moresimp.com/ (login with test/test123)

Hope it will help you

Mark 

[Ramon Padilla]

Thanks for your reply.

if you install Agile/Software and look at the defaults, you will find that sub-tasks do not have estimates 

I have got JIRA Agile installed. IS that what you mean by Agile/Software? If so, then subtasks most certainly do have estimates. Please can you clarify.

I don't think sub-tasks will ever be part of the backlog because they are subordinate to their parents, and move with them 

Yes, I understand the reasons for this and I've seen the many questions posted on this forum on this topic. But none really address when a subtask should be created.

[Nic Brough -Adaptavist-]

Yes, in JIRA 6.4 and below, we had JIRA + the Agile add-on (and older versions of that are called "Greenhopper"). In JIRA version 7, the Agile add-on has been re-written as an "application" and what was JIRA + Agile is now called JIRA Software. There are differences in things other than the name and distrubution method, but for most usages "JIRA Software 7" = "JIRA 6+ Agile Add-on" You may well have added estimates to sub-tasks in your installation, but in the default setup, they don't have them. JIRA Core lets you add them, but the Agile stuff does not expect you to use them, and doesn't handle them properly. Which is really quite annoying, and leads me to tell you to avoid using them in Agile. As for *when* a subtask should be created - the answer I gave boils down to "when you think you need them". In some places, people like to break up stories when they arrive, others won't do it until the story is being considered for inclusion in a sprint, and others won't do it until it's in a sprint and they're trying to work out which developer(s) should take parts of it on. Trying to use them to estimate stuff makes it more complex, but the answer to "when" is "when it suits you and your processes best".

[Nic Brough -Adaptavist-]

oops - I wanted to add that one reason that trying to use them for estimates makes it complex is that if you add them *After* they've moved on from the backlog breaks all your Scrum processes because estimates only matter on the parent issues. So if you do have estimates on sub-tasks, never add subtasks with estimates after it's been added to a sprint. Do it before, and make sure the parent includes the numbers. Or better, don't estimate on subtasks.

[Ramon Padilla]

Thanks for the info. The reason for me asking the question is based on how others might handle a typical scenario as described below. Perhaps I should post a separate question? Some tasks require that an artefact is reviewed and approved before it is considered complete. E.g. documentation or code. During our planning we include the review effort in the estimate of the task as follows: Engineer 1: Write document. (4h) Engineer 2: Review document. (1h) Engineer 3: Review document. (1h) Engineer 1: Update document. (1h) The total estimate would be 7h, 5h of which is allocated to Engineer 1 and 1h each to Engineer 2 and 3. We capture that info in the description so it is clear how much review time is included in the estimate. I'm wondering if there is a better approach. Although the above approach works OK it can sometimes be time consuming when planning a sprint to calculate the hours committed to for reviews for individual engineers when they are spread across multiple issues. In the above example, the task might be allocated to Engineer 1 but only 5 of the 7 hours are actually his/hers. What do others do?

[Nic Brough -Adaptavist-]

Normally, I'd say keep the conversation in one place, but I do think this is a subject well worth re-asking of everyone. I've rambled about the problems of using JIRA Agile/Software with estimates on sub-tasks, but I really think your last comment would make a good question in it's own right - I'd mention that you've got Agile/Software, but not really mention this conversation. (I'll watch it, but in silence, so I don't lead anyone back down this path. They'll probably go there, but let's see) On my part, in this case, I'd use Script Runner to generate a new field that adds stuff up for me, but I'm interested in what others think as well.

[Ramon Padilla]

OK, I'll post a separate question. Thanks for your time.

[Alex Mukha]

Hi, Ramon!
How you fixed problem with sub-task estimation? 

[Nic Brough -Adaptavist-]

Use Jira as it was intended and do not estimate on sub-tasks