We have an API and multiple clients.
When creating a new feature, we have one ticket for the API, and one for each client.
This kinda rubs me the wrong way.
I would prefer to have one ticket written by the PO, and multiple tickets with implementation details written by developers.
We've been experimenting with sub-tasks, but it still feels wrong.
How do you guys handle this?
Hi @Morten Hauberg!
We also use sub-tasks. This works very well for us. What disadvantages did you experience with this approach?
Another idea could be to use an epic to describe the new feature and multiple issues to describe the implementation details. The epic could be written by the PO and the issues could be written by the developers.
Or you could use issue links. But that doesn't seem valid to me.
Hi @Marc Dvorschak,
Thanks for your reply.
I think it became very cluttered with sub-tasks, and, as far as I remember, we weren't able to close a ticket before all sub-tasks were done.
- You might argue that that is the only sane thing to do :)
How do you keep sanity if you have multiple implementation tasks for an api, and multiple tasks for X number of clients?
Right now we have an epic per feature, but I feel I don't have a good overview of things this way, and it also feels a bit like misusing epics. That might just be me though
Well I would try this:
Epic = New Feature (but yeah, you could say your misusing them because there is a issue type "New Feature")
Each epic would have an issue for the api changes. This issue could have a special label "API change" for example. This issue would have sub-tasks. One per implementation task.
For each client that you have to adapt, make an issue (maybe with the label "Client change"). This issue would be part of the feature epic. Then make sub-tasks for the client issues. Again one sub-task per implementation task.
Regarding how to keep track of all these issues try different boards with filters based on the labels and swimlanes based on stories and epics.
Another team at my company uses the add-on "Structure for Jira" to create hierarchies and track them. It looks interesting but I don't have any experience with it.
A new feature would be multiple user stories.
Would you add multiple user stories to the epic, the story or the sub-tasks?
I'll have to figure out how to handle smaller changes though..
"Change color of button", "Upgrade database version", etc.
Do you use tasks for that?
Hello, Community! My name is Gosia and I'm a Product Manager on Jira Server and Data Center here at Atlassian. Since 2002 when we launched our public issue tracker, jira.atlass...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs