Using the agile board, I don't see subtasks in plan or work mode. As I researched help, it's not currently supposed to.
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.
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)
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)?
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...
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.
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)
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.
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.
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.
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?
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.
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?)
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.
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
Hello all! It has been 20 years since the agile manifesto was introduced, and closer to 40 years since software development began moving away from a waterfall-type approach. While many teams have ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events