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?

[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?

[Morten Hauberg-Lund]

I tried to play around with something like you mentioned, @Marc Dvorschak, but now it strikes me that I cannot assign story points to a sub-task. 

Have you run into this "issue"?

Edit: never mind. It was my mistake. Sorry

[Marc Dvorschak]

I'm glad that I could help. 

For smaller changes like "Change color of button" or "Upgrade database version" we use normal issues in Jira.

[Morten Hauberg-Lund]

It really helped a lot. Thanks.

Last question - do you use story points?

I'd like to have story points on the sub-tasks, but that won't be sum'ed on the story.
This could of course be a manual task to do, but it's really error prone.

How do you handle estimation?

[Marc Dvorschak]

Sorry to say, but we don't use story points or Jira for estimation. My team does this the "the old fashioned way" (Excel and person-days) :D

[Morten Hauberg-Lund]

Bummer.

Thanks a lot for your help