JIRA story--> Subtasks instead of tasks

Last post 07:27 am October 16, 2021
by Balaji Dhamodaran
6 replies
Author
Messages
09:10 am March 27, 2020

Hi all,

Our team is taking transition of new project from some other team. Now, that team has created sub-tasks under stories instead of tasks. According to me it should have been Story--> Tasks-->Sub Tasks

If the same practice is followed in future, do you think it would be a problem?

I can only think of this issue - > If we create sub-tasks under stories instead of tasks, we can't drill down more if required in future. But apart from this, is there any other issue that we may come across?

 

 

02:02 pm March 27, 2020

Since the Sprint Backlog is owned by the Development Team, it is up to them on how to use it. Your answer depends on how they want to use the issue types and visualize the work.

I have seen most Development Teams use issue types of Story and Sub-task, if the Sub-task is related to the Story. If the sub tasks are a breakdown of the story, then this is a fine way to relate the work to the Product Backlog item, as it has a parent-child relationship. Then the sub tasks can be moved across the workflow.

How would you link the Story to Task in Jira?

03:02 pm March 27, 2020

Since there is nothing in Scrum that says how you actually visualize your Product/Sprint backlogs, there isn't an answer to that question.  As @Chris Belknap said, the team needs to decide how to deal with this.  But I will say that you can always break a story down further in Jira. You can link stories to each other to show the relationship.  And if you are an organization that uses burndown/burnup charts, subtasks aren't represented in the Jira charts but given you statement you already know that. 

11:44 am March 30, 2020

Thanks Chris and Daniel.

How would you link the Story to Task in Jira?

The same way we link sub-task to JIRA. I don't think there is any difference.

 

Subtasks aren't represented in the Jira charts

I am not sure about that. As per the Atlassian-:

Subtask behavior when remaining estimate and time spent is enabled: parent task will have the total sum of all remaining estimates of the subtasks.

Subtask behavior when remaining estimate and time spent is disabled: 

(a)If you add a subtask to an issue that's already in an active sprint, the subtask is also treated as scope change.

(b) However, scope change is not indicated in the Burndown Chart for the subtask.

(c) Time estimates are tracked individually across the subtasks and the parent task itself.

Reading above information I feel, if we keep updating remaining time , time spent etc for sub-task, the same will get reflected in burn down chart if at all we want to see burn down for hours spent/remaining for each story.

 

 

 

07:18 am October 15, 2021

I would like to recommend another approach:

Instead of sub-task, we prefer to create tasks with "Linked Issues"  field as "split from" and the following "issue" field enter the  parent user story/task.

It may require a little bit more effort to create task, however, far more flexible.

05:33 pm October 15, 2021

Hi, Vishal!

What do you think is more important for your team? Following a particular method to structure your Product and Sprint Backlog or following a method that the team believes would add clarity to its process and improve its communication?

Is not possible to try one option and if it doesn't work as expected try the other one? Is the decision taken about how to structure the product backlog irreversible? Is this actually a paramount problem for the team? 

How the first value of the Agile Manifesto (individuals and interactions over processes and tools) applies to this case in order to facilitate the best decision?

 

07:27 am October 16, 2021

In my experience, these Work Breakdown Structure detailing has not helped the team much instead it increased the Jira administrative work. Having many layers like task, subtask all could make the transparency hard to the whole team. You and team will be lost after some sprints and stop doing many things. So start with simple and add what is required when your team finds out by learning. The visibility should be as simple as possible so any stakeholders also can understand.