Pro. Services: projects or components?

[forum question]

We're having a discussion about the best way to handle pro. services engagements in JIRA. The main concern is that projects (some heavily) will contain issues that are actually tracking feature work in a product (i.e., they already have issues created for them in the product project). So to keep that data in sync (without manual duplication) is it best to create each engagement as a component under the project for the product rather than to create a separate project?

I understand that issues can be linked and cloned, but does that only work well within one project?

For exmaple, "'Cloning' (copying) an issue allows you to quickly create a duplicate of an issue within the same project." (from https://confluence.atlassian.com/display/JIRA/Cloning+an+Issue)

I'd like to hear some opinions about how well that actually works in the real world.

Thanks

[Norman Abramovitz · Accepted solution]

Linking does work across projects, so you if I understand correctly, I would expect you to create an issue under your customer issue project. This project would have links to the product project issues. You can then keep customer interactions separate from the development issues. I would expect your workflow to be different for the customer issue project from the development workflow. There is no duplication of issues using this type of mechanism.

[forum question]

Thanks Norman, how exactly would you create a relationship between two issues across projects?Does one have to create two issues (one in each project) and then link them somehow?

For example, the issue linking option of "cloning" is not correct because their is no relationship between the two after the clone. So if clone isn't the right option is "duplicate" the feature that allows an issue to be kept in sync across two projects?

From JIRA Help:

"The clone issue can also be linked to the original issue using a 'clone' link.

A clone issue is a separate entity from the original issue. Operations on the original issue have no effect on the clone issue and vice versa. The only connection is a link (if created) between the original and the clone issue."

[forum question]

Norman, your comment seems to contradict the comment from Renjith above. Have you tried linking across projects and found that the issues can stay in sync?

[Norman Abramovitz]

We use the related to link type. When linked issues are resolved, it shows up with a strike through. So if a customer issue is dependent on three development tasks, the customer issue has three related links and when those links gets striked through, we know that the development tasks was completed.

There is no duplication or cloning because we just click through to the real Jira issue and see the latest status.

Yes, you need to create the two or more issues. Since your question stated that you may have a development issue and you are creating a customer issue, you have your two issues.

Do you have one project for all customer issues or multiple projects to cover customer projects depends on your company/product structure.

We link across Jira projects(as well as external web pages) all the time as noted by the documentation links given below.

https://confluence.atlassian.com/display/JIRA052/Linking+Issues

http://blogs.atlassian.com/2012/03/jira-5-remote-issue-linking/

[Karie Kelly]

We track our customer implementations in a single project, but use the FixVersion to define the project. That way, we can associate issues within that project to one or more fixversions and much of the reporting/gadgets already available to you utilize fixversions.

For other types of projects that cross multiple disciplines (e.g. large projects or sets of features, usually to meet a contractual obligation), we use labels on the issues. Therefore, if the project was called ABC, we put abc on any issue related to the project. Then, create a Kanban board that is based on a filter that pulls in all issues with label = abc.

BTW -- you can clone in a project and then use the Move feature to move it to a more relevant project. Even in the same project, if the issue type has different workflows, you use the Move feature because you are changing workflows.

[Renjith Pillai]

Creating a separate project can result in lot of overheads, for example to keep the versions in sync, administration efforts to keep them all same, users confusion on where to create issues.

Decision on a single project or not mainly depends on whether that entity has different versions to track, different internal components, and probably different project administrators, different types of workflows for same issue types etc.

[forum question]

Thanks for the comment.

We're not talking about tracking versions, users, etc. in two places. The question is specifically about issues. Is it easy to sync/update/track the same issue across two projects without manual work?

[Renjith Pillai]

There are not built-in solutions for achieving sync between jira projects. What I can think about is either use REST apis directly to run a filter daily and keep the issues in sync. Or use the CLI to do the same if you would prefer it using a script.

This will not be a complete solution, but can help you in achieving it to some extend. Also remember the cases in which you need to decide if an issue is updated in both places on the same day.

[forum question]

Renjith, thanks for the comment. There seems to be an awful lot of confustion out there about what "linking issues" means.

How would you accomplish the goal here? Would you have each engagement as a component and use one JIRA project for the whole company?

[Renjith Pillai]

One JIRA project for the whole company is such a bad idea. Linking is the way to do it. But remember that except for a visual representation of a relation between two issues, Links has no other meaning in vanilla JIRA. My thoughts:

• You need to show some data from the linked issues in a issue so that the information is available in the child issue
• You do not really need an edit functionality on the child issue, and you just need a read-only representation of it
• This can be easily achieved by using script runner, create a scripted field and attach to all issues. It can evaluate the issue links and pull out the information and show in this issue.
• This will avoid all sync issues
• And for status handling, I am guessing you do not require any automatiion as the parent and child statues are indeed separate.