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?

[Elifcan Cakmak · Accepted solution]

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.

[Elifcan Cakmak]

Hi,

It makes more sense now but I still have questions. First of all, is it one product and one feature that you develop and implement? Or is it different for every client and you develop the feature specifically for every client? Because I couldn't understand why it would be a problem for Client Y, since you would develop and implement the feature already on December 10th. So I assume the feature is developed according to specific needs of the client. And when you don't close the issue on December 10th, Client X would say why it is still open. Is that correct?

If it's a matter of reporting, maybe you can use subtasks. Subtasks are not designed for a  purpose  like this but you can open one subtask for each client and keep different due dates for all of them. If you are using Script Runner you can search and create a filter like this: issueFunction in subtasksOf("project = KP") and see due dates separately.  For example when you finished the work for Client X, you can close the subtask and continue working for other clients. I hope it makes sense.

Best regards,

Elifcan

[yanir]

Yes, it is a matter of reporting and the ability to track progress. It is exactly the same requirement for both clients - at first, we will build only things that will go to the generic product. (that's why I stress that we are talking about R&D and not professional services, or tailormade system integration) 

So I assume that what you are saying is that indeed Jira does not cover this scenario which helps me as well as I know that I do not have to search for something that does not exist.

I will either adopt this subtasks workaround or create a set of custom fields fields

[Elifcan Cakmak]

Yes, that's what I was going to suggest next, creating a date custom fields for every client but that's way harder to manage than subtasks. 

I have never encountered a similar scenario unfortunately and when I researched a bit, I couldn't find anything similar either. I believe default Jira behavior suggests that you clone one issue and adjust the cloned ones according to client and progress, but it is understandable that you don't want to deal with more than one issue for one request. That's why I believe subtasks would be the best solution for you.

I hope it helps.

Regards,

Elifcan