How to create a structured shift handover in Jira

Define the handover boundary

The handover covers work that still needs an operational decision after the shift ends. It does not need to reproduce every completed ticket or every message sent during the day. Agree a cut-off time, the receiving team and the set of services or Jira projects in scope before collecting items.

A useful test is: if the next shift could act incorrectly because this item is missing, include it. If the information is already current in a Jira issue and needs no transition decision, link the issue rather than copying its entire history.

• Set a clear time window and receiving queue.
• Include open risk, blocked work and time-bound follow-up.
• Exclude resolved items unless a residual risk remains.

Find candidate Jira work

Use a Jira saved filter or advanced search to inspect work in the projects the shift owns. For example, the query below returns non-completed items in an illustrative OPS project, ordered by the latest issue update. Replace OPS with your own project key; adapt status and ownership rules to your workflow. Jira permissions still govern which issues each viewer can see.

A Jira filter is a starting list, not the handover itself. It cannot decide whether a ticket is risky, whether a workaround is in force or what the receiving operator should do next. Handoff Pulse handover records are stored as Forge app data; do not assume Jira JQL searches their fields.

project = OPS AND statusCategory != Done ORDER BY updated DESC

Use a record that supports a decision

Give each handover item a concise title, a responsible person or team, a priority, the current state, a Jira issue reference and one explicit next action. State the observed impact separately from a suspected cause. Record blockers and risks even when no technical fix has been found.

Make the next action executable: specify who acts, what they check, when they check it and what result changes the escalation path. ‘Monitor queue’ is ambiguous; ‘On-call engineer checks backlog at 22:00 UTC and escalates if the agreed threshold is exceeded’ is testable. Store detailed investigation and permanent remediation in the linked Jira issue.

• State: what is known now, with timestamp.
• Impact: users, service or internal process affected.
• Risk and blocker: what could fail, and what prevents progress.
• Next action: owner, trigger or time, expected evidence.

Worked example: a queue with rising backlog

Example only: issue OPS-248 tracks intermittent failures in a payment processing queue. At 21:45 UTC, the backlog is rising; a temporary retry adjustment has stabilised throughput, but the cause is unconfirmed. The receiving owner is the on-call operations team. The next action is to compare backlog and error rate at 22:00 UTC with the team’s documented thresholds and escalate according to its runbook if the condition persists.

This example communicates the observation, intervention, unresolved uncertainty and decision point. It deliberately does not claim that Handoff Pulse supplies automatic alerting or changes the Jira issue. The issue remains the place to record diagnostic evidence and a long-term fix.

Close the transfer loop

Before the outgoing shift leaves, review each high-risk item with the receiving owner. The receiver should confirm it can access the linked Jira issue, understands the next action and accepts ownership. An acknowledgement is receipt of responsibility, not proof that the underlying issue is resolved.

If the receiver cannot access the issue or the escalation channel is unclear, resolve that gap while both shifts are present. Record a carry-forward item when work remains open in a later shift; preserve the connection to the previous state so repeated risk does not look like a new incident each time.

Review quality with a few defined measures

Start with three counts over the same reporting window: items awaiting acknowledgement, items with no next action and items carried forward more than once. Define the denominator before comparing teams; for example, acknowledgement rate can mean acknowledged handovers divided by handovers due for receipt in the period. A high count is a prompt to inspect context, not automatically a performance judgement.

Also sample one or two handovers each week: could a colleague who was not on the outgoing shift reproduce the next step without a separate chat? If not, improve the template or escalation rule instead of adding more mandatory prose.