When using Jira, we can create a ticket with subtasks. I can see the subtasks being moved along the columns, but I don't understand the proper way to handle the parent task. It can be confusing if the parent task is moved to a particular state while the subtasks are in different states. How is this supposed to be used? For example, is the parent task meant to be "invisible"? If so how? The context is the best way to break down a big story into subtasks, and it seems a story with subtasks is the proper way but seems a bit confusing.
4 Answers
Personally, I prefer treating the parent story as I would if there were no subtasks.
That means, as soon as someone starts working on one of the subtasks, the parent story moves to In Progress. It will stay In Progress as long as any of its tasks are being worked on or could be picked up. In fact, an advantage of having the story marked In Progress is that it becomes clearer that this story's unstarted tasks should take priority over another story that hasn't been started yet.
Similarly, if all of its (remaining) tasks are currently Blocked, that means the story is Blocked. You also could argue that it's blocked if any of its tasks is blocked. Just define a clear rule and follow that.
You can apply similar rules for other columns. For example, the story as a whole is Ready for Testing once all its tasks are either Done or themselves Ready for Testing.
And of course a story can only move to Done when all its tasks are Done.
One thing that needs to be established right away is the fact that this is a team effort. While the product owner is responsible for prioritizing the backlog and capturing requirements from the business and the users, the developers are really the ones best positioned to understand what in terms of technical capabilities must be developed, as well as the level of effort entailed.
There are a few important things to consider when breaking down user stories into tasks:
Keep tasks small, but not too small. As a rule of thumb, a task should be something that can be done within a single day, but not in a few minutes' time either. Keep tasks very precise in scope. Don't create tasks with such vague statements as "Coding" or "Implementation" thinking that anyone can just refer to the parent user story for details. Write something more meaningful that also makes the scope very clear. For example: "Develop the login class." Use the user story's acceptance criteria as a starting point, and its definition of done as a checklist. The acceptance criteria will help you determine what features need to be implemented, and the definition of done is a checklist for all user stories that can also help you determine if you're missing any tasks for the story to be done.
This depends on your workflow - both the issue workflow for the parent task and subtask as well as the columns on the board to represent that workflow. It also depends on what your parent and child tasks represent.
For teams that I work with, the parent issue has the primary workflow. For example, the parent issue will progress through states like "To Do", "In Development", "Code Review", "Integration", "Ready for Release", "Released" while the subtasks will be "To Do", "In Progress", and "Done". Depending on what the subtask is and how it relates to the parent will affect when state transitions happen. If the subtask is a development task, it would have to be "Done" before the parent can progress to "Code Review". But if the subtask is an integration and test activity, then it would be "Done" before the parent can move to "Ready for Release". And if the subtask is a release activity, then it would be done before the parent becomes "Released".
Personally, because of questions like this, I like to avoid the use of subtasks as Jira issues. For task decomposition, I typically add a list of work to the issue's description field or add a custom field, but there are also checklist plugins that let you add them as checkboxes that can be ticked off. If there are tasks that can be put through the development workflow independently, then it becomes a new top level issue and appropriately linked using relationships like "blocks" or "is split from" or "relates to" depending on the nature of the relationship.
answered Feb 19, 2022 at 14:28
-
1I don't like the description field or tickbox as you say because if at story has multiple subtasks (always talking about software tickets), then the story can remain e.g. in progress state while there is no visibility that some of the subtasks are completed. Isn't that for you a disadvantage? A second question is what are these links "relates to" or "split from"? Are they standard in JIRA?– JimCommented Feb 19, 2022 at 17:08
-
Actually I did find those now. What is the diff of "split from" and "relates to"?– JimCommented Feb 19, 2022 at 17:10
-
@Jim If your work so big that there's no visibility for progress in a couple of days, it's probably too big. I've found that the most useful purpose of task-level decomposition is to help the team understand and size work. As far as the types go, it depends. I use "split from" to indicate that I took a slice of work and moved it to a new issue - for example, one may capture implementing a "happy path" while others handle alternate flows or more robust error handling paths. "Relates to" is just a generic relationship. How you use these is more about convention rather than anything else.– Thomas Owens ♦Commented Feb 20, 2022 at 12:47
It's far easier to follow up on the parent story as if there were no subtasks than it is to follow up on anything else. Once a subtask has been performed, it is moved to "in progress," and the process continues until all tasks have been finished, bringing the parent story to "done".
This weeds out confusion.
