You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.
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 :-)
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 :-)
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!
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.
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. :-)
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.
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.
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.