Linking tasks to stories - wrong or right?

Colum McAndrew August 11, 2021

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 :-) 

3 comments

Comment

Log in or Sign up to comment
Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 12, 2021

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.

Like # people like this
Colum McAndrew August 12, 2021

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 19, 2021

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!

Like Colum McAndrew likes this
Colum McAndrew August 19, 2021

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 20, 2021

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 23, 2021

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.

Like # people like this
Marjorie
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 18, 2021

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.

Like Colum McAndrew likes this
Colum McAndrew October 18, 2021

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.

TAGS
AUG Leaders

Atlassian Community Events