Jira next-gen: Introducing subtasks for breaking down work
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.
					
				
			
			
			
				
			
			
			
			
			
			
		