Introducing subtasks for breaking down work in next-gen projects
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-defined chunks.
Based on our research, we know that this often starts as just needing to capture any additional steps to complete a piece of work. As a team grows or their scope of work expands, there also becomes a need to capture additional information about the broken down tasks and begin to track them independently with different owners. The benefits of breaking work down include....
-
Get a better understanding of what work needs to be completed and helps teams plan accordingly
-
Understand the relative size of a piece of work based on all the steps needed to complete it
-
Identify gaps and reduce the risk of delivery or running over time because of unplanned work
-
Prioritise team efforts more effectively and quickly reprioritise based on new information
Hello subtasks!
We have previously introduced epics to next-gen, and the Roadmap to track them, which provides a way for teams to capture big rocks and break those big rocks down. But as we’ve seen in the classic Jira experience, and in our research with teams coming from other tools, many teams need a way to break work down into more discrete and manageable chunks. For teams with this need, we are now introducing subtasks.
One of the most fundamental changes we have made with subtasks in next-gen projects, relative to classic, is that we now have a formalised hierarchy. In classic projects, subtasks could be created from any other issue type whereas in next-gen subtasks can no longer be created directly under epics. The following is a visual example of this hierarchy
Example: Acme Inc are about to kick off a project with the goal of increasing checkout conversion for their online shopping cart. The product manager identifies that there is poor conversion for non-English speaking countries. The feature lead arranges for the checkout to be translated based on the users locale.
What's in this first iteration of subtasks?
-
Break down an issue into subtasks via the issue details view
-
Capture additional information (description, owner, status, due date, etc.) on the subtask and configure custom fields to better suit their team's needs
-
Update the progress of a subtask and move it through the workflow via the issue details view
-
Understand at a glance which work has been broken down in both the backlog and board
-
Understand the overall progress of work via the subtask badge on cards and in the issue details
-
Visualise subtasks directly on the board with swimlanes (the project administrator controls this view)
-
Break down an issue into subtasks via the inline issue create directly on the board
-
Move subtasks through the workflow by dragging and dropping into a column like any other task
- Edit the name and icon of the subtask issue type
- Add or remove fields from the subtasks issue type
Note: It’s worth mentioning that users can also visualise other types of work that haven’t been broken down yet (or don’t require it) in these swimlanes.
You can see sub-tasks in action in our Demo Den below.
Why has this taken so long?
We’ve been working on decomposing the Jira application into microservices as we build out next-gen. With the decomposition, we are also rearchitecting how our boards work to provide us with better performance at scale and we are setting the product up for new capabilities in the coming year. The complexity of untangling 17 years of legacy code has been more challenging than expected, but ultimately the rewards we will get will allow us to move much faster in the future.
We’ve also learned from our first iteration of work breakdown, where we made epics and Roadmap available. We didn’t make the new links between epics and their children backwards compatible with classic projects which has caused some pain for when users have moved data between the project types and has introduced limitations for marketplace apps that were reliant on issue hierarchy. We have included this in the scope for subtasks, and we’ll soon be closing this gap for epics as well.
What’s coming next for subtasks?
We will be monitoring usage and feedback to help us understand the value you are getting from subtasks, and this will help inform the prioritisation of incremental improvements. For example, we already have on our radar to make the following improvements…
- Making swimlanes a user configuration rather than being an admin configuration
-
Providing more visibility of subtask estimation at the parent issue, on the backlog, and in reporting
- Allowing for subtasks to be ranked within its parent issue
-
Adding additional information in the swimlane headers when grouping by subtasks are enabled
-
Making it possible to convert a subtask to another issue, for example a story or task
What’s coming in the future for work breakdown in next-gen?
As well as some incremental improvements for subtasks, we have a number of more bigger chunks of work to come for work breakdown. These include (not in priority order)…
- Improvements to how work is assigned to epics
-
Introduction of “Actions”
-
Workflow configuration (and rules) per issue type
-
More reports and more flexibility for reporting
-
Estimation roll-up across multiple levels of work hierarchy
Please note...
For existing projects, the project administrator must add the subtasks issue type under Projects Settings -> Issue Types.
We have rolled out subtasks to almost all instances and we are in the process of completing the remainder of the rollout. If you are unable to add the subtask issue type, then don't worry it's coming very soon to your instance.
Was this helpful?
Thanks!
Eoin
About this author
Senior Product Manager
Atlassian
Sydney
46 accepted answers
118 comments