nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Linking tasks to stories - wrong or right?

Colum McAndrew

The wise and good of the agile methodology suggest that it is not good practice to have tasks linked to stories. They suggest using subtasks instead. However, for our use case this just doesn't pass muster.

Why?

We're a team of Technical Writers / Content Designers, whose work is largely led by the Software Engineers. They write code, and we explain it in the docs. We support multiple Dev teams, each of which have their own Jira project. We also have our own project, and follow a Kanban model. This is despite most of the Dev teams operating in sprints.

We operate an Epic, Story, Task, Debt, or Bug hierarchy, with the relevant linking in place to allow to see the connection between tickets. When it comes to stories, we treat these as epics, because the epic we use is normally the Dev team's epic. It prevents duplication of effort, and allows the powers to be to report on resourcing.

With the story being just a short description of the change, the detailed work required is detailed in tasks that are linked back to the story. We may add subtasks to tasks if there is work required by an external team.

The issue we have is that you can't create a task from within a story, only a subtask. This seems to indicate that we're raging against the machine. Instead we create the story and tasks separately, and link the tasks to the story with an "Is part of" link type.

I'm happy for any opinions, suggestions, or downright criticisms of this approach. I've a thick skin :-)

Comments

Jack Brickey

Hi @Colum McAndrew , thanks for sharing!

First I think it's important to point out that there's a big difference between linked issues and children of issues, at least within the Atlassian environment. Links between issues really don't have much underlying rules or behaviors. They are simply there to show relationship. However, for parent-child relationships (task-sub-task) this is not the case. There are rules and behaviors inside Jira for these.

In the Jira agile world, stories are meant to be completed within a single sprint. The same applies to us to tasks. If it is desired or necessary to break a story or task into subtasks then those subtasks equally need to be completed within a given Sprint. Stated differently, the story and all subtasks need to be sized such that they can be completed within a sprint. Also when using this parent-child relationship you can leverage the estimate some up two show within the story the total estimation from all subtasks.

In my opinion using linking the way you are here is "Breaking" the parent-child controls intended in agile practice. It seems to me that carefully laying out your stories and associated subtasks would allow you to work within the confines, if you will, that are intentionally implemented within Jira.

Colum McAndrew

Thanks for coming back @Jack Brickey. So what happens if you're not using sprints but Kanban? The reason for this discussion was a particular use case that my team really struggles with.

We're a team of Technical Writers/Content Designers who have their own project, but who are at the behest of the Product and Engineering teams. We link most of our work to a product or engineering epic, so for us our top level is a story. This seems to fit the agile methodology, as those tickets just summarise the work involved.

Off that, we have the work items. Trouble is, some of those work items have dependencies outside our team, and others can involve a lot of work. So occasionally we need that additional level - subtasks.

As always, I'm happy for other opinions. It is all grist to the mill. If it helps, I've yet to find a Technical Writing team that fits the agile model in the same way as an engineering team. We find ourselves moulding a process that meets our needs, rather than rigidly sticking to something that doesn't.

Yours raging against the machine :-)

John Funk

Hi Colum,

I am not sure why you are doing a story AND task when using Kanban. I would just create tasks associated with the Epic. If you want to link the task to the story or task on the Sprint side, knock yourself out. But it looks like you are creating hierarchy for the sake of hierarchy.

Rage on, my friend!

Colum McAndrew

Hi John. Raging against the machine is something that is second nature for Tech Writers in the agile world :-)

Our issue is that we're a reactive group whose work is linked to Dev teams. They have their Epics which we react to and create our own set of issues to do our work. But to ensure management reporting is effective their work and ours has to be linked in some way.

John Funk

Seems like you could still do linkages between the issues without having to build the same hierarchy to me. But I am not a part of the raging Tech Writer gang. :-)

Paul Stallworth

I think I'm with John here. If you're creating Epics that match the dev team's Epics so you can report up to management on the same stuff, then why don't you just stop creating Stories and only creating Tasks within the Epics? Just collapse your Story into your Tasks (or the other way around, it's just semantics at this point).

"When it comes to stories, we treat these as epics, because the epic we use is normally the Dev team's epic."

Why do you need a logical "epic", do you have bodies of work that are large enough to constitute being an "epic" in the agile sense? How come that isn't embodied by the Epic that you actually create.

And probably more to the point, what is the problem you're having other than Jira doesn't allow you create Tasks under Stories? Your initial question is about whether what you're doing is wrong or right and I'm not sure that's relevant, I'm more interested in whether what you're doing is effective.

Marjorie

Personally, I link Epics, features and stories. When my DEV team creates tasks they do so from within the story so it links them. I like linking so that when we display the product map we know what may impact the delivery.

Colum McAndrew

Thanks for that perspective @Marjorie. Because a lot of our work is led by other teams, our Jira workflow hangs off theirs. We've thought about having an epic that hangs off theirs, but that doesn't really fit the standard agile practice either. At the end of the day, you have to do what works for you, so good on you.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

task

issue-type

sub-task

story