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.
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.
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."
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.
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.
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.
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:
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot