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; } } }

One ticket, multiple implementations

Morten Hauberg-Lund

Hi,

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?

Accepted answers

All comments

Marc Dvorschak

Hi @Morten Hauberg-Lund!

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.

Morten Hauberg-Lund

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

Marc Dvorschak

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.

Morten Hauberg-Lund

Sounds reasonable.

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?

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-server