Jira handover checklist for operations teams

Set the scope before collecting items

Choose the shift window, receiving queue, Jira projects and services in scope. Include unresolved incidents, scheduled checks, blocked deployments, customer-impacting changes and risks likely to outlive the shift. Exclude routine completed work with no remaining decision.

A saved Jira filter can help find non-completed work. This illustrative query shows issues updated recently in project OPS; adapt the project key, time window and status logic to your team. It does not search separate handover records stored by an app.

project = OPS AND statusCategory != Done AND updated >= -1d ORDER BY updated DESC

Outgoing shift: verify each open item

Read the linked Jira issue, then write the transition summary in the place the next team expects it. Avoid relying on an old issue title or an unverified priority. The snapshot should be current enough for the receiver to make the first decision without reopening the full chat history.

• Service and issue key identify the work.
• Current state has an observation time and distinguishes facts from hypotheses.
• Impact, risk and blockers are explicit; a temporary workaround includes its review point.
• One owner, next action, trigger or deadline and escalation route are named.
• Linked evidence is accessible; secrets and unnecessary personal data are excluded.

At the handover: test comprehension

Review critical or time-bound items together. The receiving operator should be able to restate the next action, access the Jira issue and say when it will escalate. Do not infer comprehension from attendance in a call. Where your process has an acknowledgement step, record receipt and identify any item still awaiting an owner.

Keep status distinctions precise: ‘received’ does not mean ‘resolved’, and a Jira issue assigned to a developer does not automatically make that developer responsible for the overnight operational check.

• Can the receiver access the evidence?
• Is the owner of the next decision available?
• Are the threshold and escalation route agreed?
• Does any open high-risk item lack acknowledgement?

Incoming shift: act and update

Start with time-critical checks, then blocked or high-impact work. After an action, update the Jira issue where the issue state changed and update the handover state where the transition decision changed. Do not create competing copies of the same fact in chat, spreadsheet and issue comments.

If a handover item remains open at the next boundary, carry forward the unresolved decision, note the new observation time and link it to the prior context. Close it when there is no further transition action, even if the related Jira issue remains open for long-term work.

Weekly quality review

Check a small sample of handovers against the checklist rather than treating every field as a reporting target. Count missing owners, missing next actions and unacknowledged due items. Examine repeated carry-forward for dependencies or an unclear definition of done.

If the same service produces repeated handovers, open or update a Jira issue for root-cause work. A good checklist should reduce missed follow-up; it should not become a parallel ticket system.