The golden rules of collaborating with Confluence and Jira

Below, you find some golden rules you should follow when collaborating via Jira.

An issue needs a clear description of what needs to be done

The description needs to be of a quality that any project member can understand what needs to be done to resolve the issue.
Results from oral conversations about the issues (e.g. during a call) have to be documented in the issue.

One project task per Jira issue

One Jira issue must contain exactly one project task to be resolved.
It is quite normal that - when working on an issue - new issues are being identified.
In such cases, one or several new issue(s) shall be created.
The relation to the originating issue shall be reflected by - depending on the relation type - by linking the issues or creating (SUB-)TASKs.

Maintain relations between issues

Commonly, issues have relations between each other or to other content.
Making them transparent significantly increases execution effectiveness on a project.
So related issues should be linked, or their hierarchy represented by child issues. Also, issues can be linked in other content or other content linked in issues (e.g. a requirements specification).

Figure 1: Create subtasks

Progress on a work item is properly documented

The progress on a work item shall be documented by suitable means and updated regularly, especially after meaningful changes or findings. This ensures transparency, traceability, and allows others to follow the current state of work at any time.

This can be for example:

1. Sharing intermediate results which had been achieved (e.g. results from an analysis) as comments
2. Linking a Git branch which allows to monitor progress on the branch
3. Linking new work items which had been spawned as result of the work on a work item
4. Linking other artifacts which have been generated during the work on the work item (e.g. a Confluence page)

The assignee is the one who has the next to do

No matter who that is, the one who has to do something next is the assignee.

Warning

To ensure project progress, always keep the assignee up to date.

Note

If it feels that several people should be assigned, this is a clear indicator that several tasks were included in one issue (see above).

If somebody is waiting for someone who is not a member of the Jira project, the issue can remain assigned to the one who has given the task to a non-project member but should be set to the state WAITING.

The next "to do" is apparent

Either via the issue description or via a comment, it is clear what the next step is to resolve the issue.
If this has been identified in an oral conversation (e.g. in a call) the issue is updated with that information.

The source of the issue is apparent

The following information applies only to customers with a Customer Collaboration Space. Customers without access to such a space can find registration instructions in the Registration section.

The reporter is representing the originator of the issue.

Note

One can set somebody else as the originator.
So when for instance in a call somebody creates an issue on behalf of someone else this person should be set as a reporter.

Meeting preparation

Customers not having a dedicated collaboration project must refer to Jira registration.

Each issue includes a custom field labeled “Next Call”, offering three options: Tech Embedded, Tech Cloud, Business, and Management.
Stakeholders can use this field to indicate the type of discussion needed, helping compile a list of topics for the next meeting.
This ensures relevant issues are organized and ready for discussion.

Figure 2: Next Call

Actionability

Information is actionable when its recipient can undertake further actions or make decisions based on it.

When communicating, we should make sure that we provide actionable information to our counterpart(s).

Let’s see a few examples that show how to provide practical value:

• If you cannot achieve what you are asked for, let your counterpart know so that the other person(s) can plan accordingly, avoiding possible misunderstandings and needless waiting.
• If in an issue there is something wrong with the approach: let’s explain why (or offer to) and provide an alternate approach, rather than just veto the change.

That way we are twice useful:

1. both parties are offered a chance to learn

2. we can still achieve the goal, even if by different means

If you don’t know the answer, one should always offer to find it out or help the requester finding it.