How to Confidently Share Jira Data With Third Parties (Hint: Use Confluence, Too)

[#1]

Project managers are often pulled in two separate directions by the people they serve: their team and clients. Developers want to protect their autonomy, while clients want to be kept in the loop. 

This can be a tough balancing act, and I know that from experience. I can safely say one of the trickiest things to get right is communication. It's why we developed Jira Snapshots for Confluence , a specialized app to help people preserve data and use it to keep everyone from team members to clients and other stakeholders up to date. 

Clear communication is critical because technical projects move so swiftly that it's nearly impossible to get a good read on the status of a project in a given moment. 

On one hand, the development team continuously juggles challenges from scoping and budgeting questions to technical feasibility, bugs, refactoring needs, and administrative tasks (i.e., onboarding new team members, vacations, etc.). On the other hand, clients are also facing their own challenges, including making critical decisions, consolidating a vision of the solution, rallying stakeholders, and obtaining authentic and impactful feedback. 

For these two sides to effectively collaborate, it’s vital to construct a well-curated information flow.

As a project leader, one of my main tasks is to create a shared vision of the project without flooding either the development team or the client-side with too much information:

Developers should be shielded from the minute details of the organizational friction and indecisiveness created by the customer team as it works out a common understanding of the project goal.
Clients don’t need to get bogged down by every bug that the developers find and fix — especially when it’s long before the prototype is even ready.

In a sense, the challenge is the same as you’d find with a service desk. You want to keep the person who submitted the service ticket up to date, but there’s no need for them to see what’s going on behind the scenes. Of course, in a project scenario it’s not about a single service issue but about the whole operation, so the internal setup and customer-facing setup must work efficiently in tandem.

How to use Jira and Confluence for project collaboration

Jira is where your internal development work happens. The Jira instance is used for all different projects and is your team's main playground. The sprints rhythm, the Kanban board columns, and the custom fields and permissions follow a common framework. Even the split of issues to different projects should follow your internal organizational structure and is not dictated by a specific customer project.

This is the key point: the customer does not have access to Jira. It is your internal kitchen, and there aren’t any client “chefs” allowed.

This configuration is extended with custom fields, which create the foundation for sharing information with the customer.

1. Customer project: When issues related to several customer projects are managed in a single Jira project, this field associates the issue with the customer project.
2. Notes: This field is solely used by the project manager.
   1. The team knows that they should not use or modify this field.
   2. Ideally, the project manager reviews this field weekly and updates it to reflect the current state of the issue.
   3. The language and level of detail should be relevant for the customer, highlighting specific information requiring their attention. For example: “Information provided to your purchase team (David Nusbaum, email 12/9/2021), and waiting feedback,” or “Currently in internal testing, expecting to install on UAT environment around the end of October.”
3. Customer status: This field communicates the status of the issue from the customer perspective.
   1. It’s like the field “Status name to show customer” in Jira Service Management.
   2. The project manager can handle this field manually. It can be set when they review the “notes” field, or automation can be applied to calculate it directly as a function of the workflow status.
   3. It is essential to have one status like "Waiting for customer" to flag issues requiring the client's immediate attention.

Note: The development team stays out of these fields. The project manager’s role is to regularly review each issue and keep the notes and customer status current.

What’s Confluence’s role, and what needs to be configured?

Confluence is where the collaboration with the customer happens. Each client project has a space, and that’s the only area they can access.

Now that Jira is on the Cloud, it’s easy for the project manager to create a new Confluence for each customer project. This way, you can have many spaces in that instance, each for another project with the same customer or serving different areas of the collaboration.

Regardless of the scenario, Confluence should have the following parameters:

• Any development team member who needs to collaborate with the customer has access.
  The customer team has access.
  It’s installed with Jira Snapshots for Confluence, which is configured to retrieve data from Jira.
  There is a status page where the customer can view all the Jira data that applies to their project.

The customer-facing status page is the key to keeping the customer in the know. I recommend using Jira Snapshots for Confluence to display the Jira data in the most impactful way:  

1. First, each time you complete the weekly update and cleanup of the data in Jira (paying particular attention to the notes and customer status fields), take a fresh snapshot of this status page in Confluence. 
2. The JQL that retrieves the data should be tuned to get only the issues of that project, so there is no way that data from other customer projects can leak here. 
   1. For example, a JQL that retrieves only Epics from the project DEVT, which belong to the customer project “Blue Sky”, like this :

   2. “project=DEVT AND "Customer project[Dropdown]"="Blue sky" AND issuetype=Epic” 

3. You also have full control over which fields are shown, so the customer doesn’t see any fields used for internal communication. For example, avoid bringing in the field “description” if your team often puts technical details in there that should be kept private.
4.  Also, be sure to set up the page so that the customer has NO edit permissions. That means only the project manager can dictate when a new snapshot is taken — and then there’s no risk that snapshots are taken at “uncontrolled moments.”

If you’re like me and have issues organized in epics, then you’ll want the snapshot to be organized in epics as well. Jira Snapshots can do multilevel reporting, so that’s easy to set.

Last but not least, the DIFF view provided by Jira Snapshots is invaluable. It helps the customer see what changed from the previous week. For example, I had a customer who reported, “Just having this DIFF view shortens my review time three times. I no longer need to rely on my own memory to identify what changed.”

Now that’s customer service!

So, for example, if I have a status meeting with my customer each Wednesday afternoon, then my routine looks like this: 

• On Wednesday morning, I review and update the Jira data.
• Then I take a fresh Jira Snapshot on Confluence. 
• The customer is “watching” the Confluence page, so they get an automatic notification about the update and can review the page ahead of the meeting.

This way, the meeting is easy to prepare and flows very efficiently. The “notes” and “customer status” provide the client with the information they need to help the project move forward.

A setup that works for many situations

Now that you have a simple setup that checks all the boxes for your internal team and the client, you’re in business!

Your development team works how they want, with full autonomy, and the customer gets the information they need. Best of all, there is no double booking, and you, the project manager, isn’t asking for favors from your system administrators to get the job done quickly and painlessly.

The flexibility of this setup doesn’t stop here — there are plenty of other scenarios that can be solved with a similar setup. For example, you can use this setup report on Service Level Agreement (SLA) performance with third parties when there is a need to go into each support ticket (or perhaps only specific tickets). Additionally, if your organization has multiple Jira instances, you can also use this setup to make certain information visible to a group not on your Jira.

What other situations can you think of that this setup can help make your life easier?

After all, getting a good night’s sleep is the ultimate goal, especially for busy project managers. If you have any questions about how Jira, Confluence, or Jira Snapshots for Confluence can work best for you and your company, let me know in the comments. I’m happy to help!

PS: Jira Snapshots for Confluence is available on Cloud and Data Center