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

Managing same feature that is requested by different clients

yanir

Hi,

Our R&D managing Jira using one project and when a feature comes from a client we label it after the client so we can create a filter and see client's specific requests.

The challenge starts when the same feature is requested by more than one client, which is not a rare case - than due dates can be different between projects, priority and so on.

One would suggest that I will always take the conservative approach but it is still problematic - a report on one project can show me that I am late and I will communicate it to the client whereas actually, I am late only because of another client.

Is there any practice to address this situation?

Accepted answers

Elifcan Cakmak

Hello,

Is "client" here a person? You can create the same issue more than once. For example you can clone the issue, change necessary fields like due date, priority and label it with a different client.

But if "client" is a company I would recommend using different projects for each client. It would be much easier in every way.

Regards,

Elifcan

All comments

Elifcan Cakmak

Hello,

Is "client" here a person? You can create the same issue more than once. For example you can clone the issue, change necessary fields like due date, priority and label it with a different client.

But if "client" is a company I would recommend using different projects for each client. It would be much easier in every way.

Regards,

Elifcan

yanir

Thanks Elifcan.

The clients are companies. Having the same feature in different projects means to maintain the same issue exactly twice. Effort estimation, progress, flags...I wonder if there is a better practice, especially that in the end of the day it all goes to the same product version as nothing is in specific branch,

Elifcan Cakmak

Hello,

One thing that I can think of is Service Desk. You can use service desk to get the requests from your clients. Then in your main project you can create one issue and link all the requests from your clients to this issue. This way your clients can track their requests separately on the customer portal and you can use the Jira issue to progress your development. When this main issue is closed, you can automatically close the requests.

There is something that I would like to ask, what do you mean you can be late because of another client? How does your development process work? Maybe with a little more information we can think of a better alternative.

Best Regards,

Elifcan

yanir

Thanks again for your reply,

I must have not explained the situation properly. First, it is not like a support mode with emails and alike. It is a B2B system that we deliver as a part of gathering requirements.

So on Monday, I could have a workshop with client X and they say that they need a feature of Diagram that should Finance Trade over the years until December 10th.

--> I opend a userstory that describe the requirement and set December 10th as the due date and labels it as "ClientX". From that point, the feature will be part of the product.

--> 3 days after, on Thursday another workshop with another client, Client Y and they want the same feature exactly. He needs it for December 20th

--> As R&D already has an issue for that I will not open a new issue, I will just add the label "ClientY"

--> Now December 9th I run two filters, one by Label ClientX and I see that only 50% of the work was done for this feature and it should be delivered tomorrow - I raise a flag to X client. I run the same filter but with Label "ClientY" and this user story appears as risk whereas actually, I have to deliver it only on the 20th.

Of course, it is a simple example, In my case, I run an operation with tens of such scenarios and I only involved in the big picture - the team leaders know the details - and I see more flags than what we actually have.