#JIRA CLIENT APPS INSTALL#
Install Backbone Issue Sync for Jira and configure synchronization of both projects on the same instance. 
Configure a second external project on the same instance where customers can collaborate and interact with the consulting team. Create an internal project where all consulting partners, developers, and project collaborators can work freely in the way that suits them best. Instead of using ugly copy-paste workflows across instances and projects, and instead of accepting painful compromises from having consultants and clients sharing a single Jira project, issue data synchronization with an app such as Backbone Issue Sync offers an elegant solution within a single Jira instance. The Solution: Sync Jira Data Between Two Projects in the Same Instance Users may unintentionally create comments with no security level attached, exposing sensitive information. There is a major drawback here as well, though: If an issue is cleared of sensitive information and made public at a later point, the issue's history will still contain the sensitive infoįor comment communication, changing the security levels of comments can hide them. Users may inadvertently create issues with no security level attached, exposing sensitive internal information. No option to hide only some of the information in an issue, only entire issues. Below are two common examples.įor issue data, using the issue security level is an effective way to limit visibility. There are ways to limit this visibility out of the box, but they come with compromises. Jira defaults to open transparency of issue data in such scenarios, which isn't ideal when the two parties need to see different information. To solve the problems of using two different systems as described above, some organizations use a single shared instance of Jira for both the clients and the consulting partners. Two Parties, One Jira Instance, Many Challenges This is obviously a painful and inefficient process – whether utilizing Jira or another tool – and not least for the hapless folks tasked with performing all of that copy-pasting. Some organizations maintain a customer-facing ticketing or project management system, and mandate copy-paste workflows in order to get the relevant updates transferred over to a separate system for the consulting partners. And of course the client requires visibility into the project to let them know that everything is (or isn't) on track. The customers' voice however is crucial, so they also need to be able to interact with members of the consulting team at certain points to move the project along. While sharing a platform like Jira to manage a project is essential for efficient communication and achieving a common understanding between the client and the service provider, the information that each side actually needs to access differs dramatically.įor consultants to do their best work they have to be able to share information freely with one another, without the risk of internal discussions being communicated over to the clients. Clients and Consulting Partners Have Different Information NeedsĪ prime case for limiting Jira's transparency that we often see both inside and outside of K15t, is with consulting projects. This is where having a way to sync Jira issue data between separate projects within an instance can be a game changer, taking the pain out of managing who has access to what. 
We've found however, that when project demands require collaborators to limit Jira's transparency, things get tricky. And it's no surprise that this philosophy is built into the Jira product, since Atlassian really does live th eir Open company, no bullshit value, preferring as much internal information as possible to be accessible to their teams and partners. This 'open by default' quality is one of the things that differentiates many Atlassian tools from their competitors, in fact.
Openness is a fundamental characteristic of our favorite agile development tool, Atlassian Jira.
0 kommentar(er)
