When I started using Jira to manage our project backlog and sprints, I ran into a problem. We were assigning subtasks to our user stories but the Sprint Board did not show subtasks. This meant that developers could not easily see which tasks were assigned to them and no one could easily see the status of the subtasks.
For example, here is a Sprint Board with issues that have subtasks and users assigned to them:
When the issues are filtered by a user, only the issue Demo-2 is shown.
Issue Demo-1 has subtasks with the user assigned to one of the subtasks and unfortunately, this subtask is not shown when filtering by the user.
I figured there had to be a way to work with subtasks, so I did some searching online. Unfortunately, I could not find any good answers, so I started thinking of alternatives.
One idea that I came up with was to simulate subtasks with a checklist. I searched through the Atlassian Marketplace for checklist plugins that could meet our requirements. I found a couple that looked like you could assign people to a checklist item so I gave it a try.
As you can see in the screenshot below, the first checklist item has @Jason assigned to the task.
Unfortunately, the process of assigning the checklist item to a developer just produced nicely formatted text in the checklist item, but did not actually assign the item to the developer. If you tried to filter the Sprint Board by the developer, those tasks did not appear. On top of that, notifications did not get generated when a person was assigned to the checklist item. So I went back to looking for a way to work with subtasks.
Then one day while I was on the Sprint Board page, I noticed a little select box on the right side of the screen.
It said “Group By: None”. I opened the select box and saw that there were two options: Assignee and Subtask.
I selected the Subtask option and lo and behold I had found the answer!
When grouped by subtasks, each issue that has subtasks has a new view with the main issue being in a bar that crosses all of the status columns (i.e., to do, in progress, etc) and then each subtask in the issue is visible under this bar and can each be individually moved to their correct status.
On top of that, filtering by a developer works for subtasks. Hooray!
While I was happy to find a solution, I quickly realized that this “group by” view causes some difficulties.
- All issues that have subtasks are now at the top of the board and all issues that do not have subtasks are grouped under a new heading of ‘Issues without Subtask’ at the bottom of the board. This pretty much kills the ability to order the Sprint Backlog by priority.
- It turns out that the issues with subtasks are ordered by their status, with ‘To Do’ issues being at the top, ‘Done’ issues being at the bottom, and everything else in between. Unfortunately, there is no visual indicator that the issues are ordered this way and so I just happened to figure it out when I noticed the order of the issues was changing.
- Due to the way the main issue is now shown in the bar across all status columns, the issue status, story points, and labels are no longer visible.
- Filtering now has a split-personality. If an issue has subtasks, you can only filter by users or labels that are assigned to the subtasks. Filtering no longer works for users or labels that are assigned to the main issue.
- Finally, the Group By Subtasks option can only be set by Project Admins and once it is set, everyone in the project now has the Group By Subtasks view. There is no way for one user to have a Group By Subtasks view and another to have Group By None view. It is an all or nothing feature.
UPDATE — As of 2020–04–06, the group by feature is now available to all project users and each user can now have their own filter. Cool!
Even though the Group By Subtasks has some flaws, I am still glad that it exists because it makes the process of working and managing subtasks so much easier. I am glad the feature is there and have hopes that future updates will make the process a bit easier to work with.