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; } } }

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.

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.
What if subtask 1 is done in sprint1, but subtask2 is done in sprint2?
How do you handle time estimations for subtasks?

Comments

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

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)

It doesn't matter, you do stories in sprints
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).
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)?

Ruiz_ Preston

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

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!

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...

unknown

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.

unknown

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

unknown

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

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

agile

board

time-tracking

estimate

sub-task