how are subtasks in agile boards supposed to work?

[barbarat]

Using the agile board, I don't see subtasks in plan or work mode. As I researched help, it's not currently supposed to.

1. How do you plan sprints for the subtasks? If you include the parent task/story, it does not easily show you the underlying subtasks that may be involved.
2. What if subtask 1 is done in sprint1, but subtask2 is done in sprint2?
3. How do you handle time estimations for subtasks?

[Ruiz, Preston · Accepted solution]

Hi Barbara -

Regarding subtasks missing from the Work board... Are you seeing the Sprint's user stories on the Work board? If not, then you will need to start the sprint (from the Backlog/Plan board) in order for the sprint (and stories/subtasks) to show up on the Work board. If you are starting the sprint and you're able to see the user stories on the Work board, but not the subtasks, then I'd recommend following Nic's advice and check the filter that is being used for the board. You may find that the filter is excluding subtask Issue Types. If the filter is not the problem, the only other thing that I can think of is making sure you're expanding the stories (by clicking the caret for the story) on the Work board. 

About incomplete subtasks... Ideally all of your stories will be complete within a sprint, but in reality, that may not always happen. For my Agile teams, when a story is unmet in a sprint (regardless of how many tasks were not completed), the entire story carries over to the next sprint. All of the tasks completed in the prior sprint remain closed when the story carries over and only the remaining time associated with the open/not started subtasks will sum up the remaining effort. As for story points, my Agile teams don't earn points (not even partial points) for a story that's not completed in a sprint. Instead, the points will be earned in the next sprint (assuming the story is completed then).  During the sprint planning event, we will discuss how much effort is remaining on any carry over stories so that we can factor that in when determining our sprint velocity.

Hope this helps. Good luck. 

Preston 

[Nic Brough -Adaptavist-]

Subtasks are entities that belong to their parent.  Plan mode does not show subtasks because it's pointless - its nonsense to have a subtask that is more important than a story that is less important than the parent's story.  (I know, that's tortured grammar, but it's hard to explain)

So

1.  It doesn't matter, you do stories in sprints
2. You're doing it wrong - a story gets done in a sprint, so all its subtask belong in that sprint.  If you do decide to split a story across sprints, then either split the story into two, or accept that it will be carried over (with its subtasks) from sprint n to n+1 (and mess up your velocity tracking etc).
3. Generally, estimate the time to complete, put it on the issue, then log work against it as it gets done.

There is another question here - you say you're missing sub-tasks in "work" mode too.  That's not right - subtasks should show under their parents on the work view.   Can you check that your board filter definitely includes all issue types in the project(s)?

[Peter Broome]

Yeah breaking up a story between sprints basically breaks the rules of scrum...but breaking the rules of scrum seems to be the majority of real world cases.

[Peter Broome]

Yes breaking up a story between sprints breaks some primary rules of scrum...unfortunately breaking primary rules of scrum seems to be the norm in the real world! I usually use story points in backlog refinement and deem a story "ready for development" when it has enough information to assign story points and develop, then create tasks for sprint planning and assign hour estimates to the tasks...plan in points, track in hours...

[Deleted user]

I agree - in the real world it is FREQUENTLY necessary to plan sub tasks outside of stories (because of resource availability constraints etc). Yes, this is not purist agile, but it is a reality of life. Constraining the tool to conform with an Ivory Tower view of agile is to JIRA's detriment. 

[Nic Brough -Adaptavist-]

But then it doesn't work when you treat them as part of the stories.  If you're planning sub-tasks outside their parent stories, then they shouldn't be part of that story.  They're stories (quite possibly very small ones) in their own right. 

It's quite simply nonsense to prioritise sub-tasks as anything other than part of their parent.  (Sizing them is a different discussion)

[Deleted user]

Well, it may be quite simply nonsense to prioritize tasks as anything other than part of their parent in the purist world. In the real world, it is sometimes beneficial for example to start work on a sub-task ahead of the sprint when the story is scheduled to be completed. there are 1,000,000+1 reasons why that is so. I'm sure anyone who has ever had to deal with a complex program of work, involving 30+ concurrent projects, each with a complex set of requirements / targets / deliverables, will instinctively get this. In simplistic scenarios this may not be apparent.   

[Nic Brough -Adaptavist-]

In the real world, that's nonsense, you are effectively starting work on a lower priority task, and it means your issue data no longer matches the real world plans.  In those cases, you should split it out into another task to bring your data back in line with what you're actually doing.

[boardtc]

Hi Nic,

I've a situation where I have different sub-tasks assigned to different teams. The parent issue shows on one planning board (no active sprint) fine. The sub-task does not show on the second team's backlog\active sprint, despite the filter pulling it in when examined. How can I get it to show on the 2nd team's backlog? Then I can pull it into the active sprint.

Thanks, Tom.

[Nic Brough -Adaptavist-]

Sub-tasks are not needed on backlogs, they have no use there.

[boardtc]

Indeed. So it's not possible to get a sub-task on a board if the parent task is not on the same board? So more than 1 team can not work on a story.

[Nic Brough -Adaptavist-]

Er, if a team needs to work on a story, then it should be included in their board.  If you're trying to work on sub-tasks that are not part of your team's stories, then your story is in the wrong place.

[boardtc]

Not getting you. We have a story with small sub-tasks to be done by a number of teams. We are frustrated we can't manage this JIRA through each team's boards and need to edit the JIRA (sub-tasks) directly to transition. To clarify, this is a limitation that the same story can't have different sub-tasks on multiple boards?

[Nic Brough -Adaptavist-]

No.  It can.  The problem for you is that your teams have set up boards that do not include the issues they need to work on.  Either change the boards to include the right stories, or move the stories to a place where they are picked up by the boards.

[boardtc]

Sound promising! I got the story showing on each backlog but it seems a story can be only assigned to one sprint. For two different team boards there will be too different sprints, so how can it be done?

[David Stevens]

Tasks can be everything that's required to get a PBI (story) to the definition of done. If tasks are on the board it is very helpful for team transparency to see exactly where the team is at with a story.

No one person should be silo'd on a story.

[dan_marcantel]

Silo'd on a story? What a odd thread nothing about this seems correct. 

[Deleted user]

I would like to add something to this thread (I know it is old but I have not had any response to my question below and this is sort of related, maybe someone can advise?)

https://community.atlassian.com/t5/Jira-discussions/Jira-How-do-you-do-this-when-Subtasks-are-assigned-to-another/m-p/653179#M1292

The scenario is,

If say a Story has a piece of work another team must do. The easiest way to do this would be to create a Subtask under this Story and assign it to say Team B.

This works well, except, as this Subtask is correctly visible on Team B's Board which when Closed Jira prompts to Close the parent Story. This is not correct as there are still Open (albeit hidden) Subtasks under the Story. In fact the Story is assigned to Team A.

I tested this with a Story assigned to Team A
I created a Subtask and assigned it to Team A
I created another Subtask and assigned it to Team B
Both Subtasks are visible on Team A's Scrum Board, this is the correct behavior in order to maintain visibility for Team A on all work assigned (inside and outside of their team)
The Story and Subtask assigned to Team B is also visible on Team B's Board, this is the correct behavior as the work is assigned to this team

The problem now comes in once Team B completes their Subtask. The user is then prompted with “All sub-tasks for parent issue are now Closed. Do you want to update this parent issue to match?”. The natural (and obvious) behaviour would be to Close the Parent Story as no other Subtasks are visible. But by doing this the Story (that is actually assigned to Team A with open Subtasks) is Closed. This is not the correct behavior.

Possible solutions could be that once the Subtask assigned to Team B is Closed the actual Story disappears from Team B's Board (and not prompting the user to Close the parent Story)? Or possibly warn the user beforehand, with something like, "All Subtasks assigned to your team are now Closed. This Story will no longer be visible on your Board as it is assigned to Team A". Or a separate Story/Task/Subtask assigned to Team B with a link to the Story assigned to Team A is the way to go, but seems so unnecessary and not the best way to do this.

How do you work in such a scenario?

Thank you and look forward to your recommendations.

Thank you
Kevin

[barbarat]

Thanks for everyone's help. I updated my filter to include sub-tasks as you guys suggested, and they now show in Work mode (and not Plan mode as expected). Cheers!

[Deleted user]

Hi barbarat, see my question below, maybe you can assist and now that your Subtasks are visible in your team's board what do you/would you do in this scenario?

Thank you
Kevin

[JD Lobue]

d

[Ollie Guan]

First of all, according to the concept of the sprint, a story should be done in a sprint, then his child tasks should also end in a sprint.

If child tasks not completed, so the story of his superiors should also partially completed.

When you complete Sprint,you can remove the Story from the sprint, this story will continue into the next sprint

In sprint 2 you can see subtask1 is in done column,subtask2 is in to do or in progress column