Checkout testing is waiting for a payment-service change. The payment work item says Done, the checkout work item has a link, and neither team can say whether the receiving tester has the right build or contract. The relationship is visible, but the handoff is unresolved.
Managing cross-team QA dependencies in Jira means agreeing on what must arrive, who will supply it, and who will verify that it is usable. Native Jira Cloud work-item links can connect work across teams and projects, called spaces in current Atlassian documentation. Those links provide context; they do not establish the receiving team's readiness decision.
Use the following checks for a specific testing activity, such as verifying checkout against a changed payment callback. They concern native work-item links, not Premium Plans dependency scheduling or a Marketplace dependency widget. The issue keys and people used throughout are fictional examples, not a customer case or results from a tested Jira configuration.
Start by asking the receiving tester what cannot proceed and which deliverable would unblock it. A dependency should describe that concrete constraint. Two work items can discuss the same release without either one blocking the other's testing.
Suppose PAY-214 delivers the payment callback contract and SHOP-318 tracks checkout verification that requires it. Read the relationship as PAY-214 blocks SHOP-318. From the receiving work item, the inverse is SHOP-318 is blocked by PAY-214. Both views describe the same dependency. If the displayed direction says checkout verification blocks delivery of its own prerequisite, investigate whether the link is reversed or the work has been described incorrectly.
Jira distinguishes blocks and is blocked by from relates to. A relates to link gives useful context, but does not identify which item must supply a prerequisite. Administrators can configure link types, so check the actual relationship descriptions on your site rather than assuming every familiar label has an unchanged meaning.
Have the upstream delivery responder and downstream QA receiver agree on the direction and the blocked scope. If only callback verification is waiting, do not describe every checkout test as blocked. The outcome should be an agreed prerequisite relationship or a specific correction assigned through the team's normal authorized process, not an unexplained collection of links.
The documented board display shows a linked work item's relationship type, key, summary and status. In View settings, each user can choose to show Linked work items. Enabling that view for yourself does not enable it for the other team. Current documentation also warns that board and work-item experiences are changing, so confirm the controls available on your site.
Separate a hidden display from missing access or a missing relationship. Linking must be enabled, and creating links requires the relevant Link work items permission. Company-managed permission-scheme guidance also requires that permission in both spaces to view cross-space links, alongside the applicable Browse spaces access and work-item security. Team-managed projects need their own role and configuration check. Ordinary link creation does not universally require administrator rights.
If the receiver cannot inspect the prerequisite, record that visibility gap. An empty-looking board view is not evidence that no dependency exists.
An upstream work item needs someone who accepts the next delivery action. Begin with its assignee, but confirm what assignment means in that team. It may identify the current implementer or a coordinating delivery owner. A linked card and an unanswered mention do not establish that either person has accepted the handoff.
For PAY-214, ask Mira, the agreed delivery responder, to state what SHOP-318 will receive. “Finish payments” is too broad. “Provide the agreed callback contract and an identifiable candidate available in the QA environment” gives the receiver something to inspect. Record the contract revision, environment reference and condition that will allow the affected checkout checks to begin.
The owner should also identify the immediate action and the next delivery update. If the contract still needs a product decision, the next action may be to resolve that question rather than promise a build. If another team operates the sandbox, name the person coordinating that prerequisite instead of silently making Mira responsible for access she cannot grant.
Keep the delivery responder visible when the work item's assignee changes. Otherwise, reassignment for code review can accidentally remove the only identifiable handoff contact. Agree on a backup or reassignment path where absence would stall testing. These are team operating conventions, not a native Jira Dependency Owner role or an ownership relationship created by the link.
This check passes when a named person accepts a bounded deliverable, its unblock condition and the next action. If nobody has accepted, leave the ownership gap explicit and route it to the person who can resolve the assignment. A populated assignee field should not conceal an unowned commitment.
The person supplying a prerequisite and the person deciding whether it is usable for testing have different jobs. Mira can confirm that the callback candidate is available. Leon, the receiving QA owner for SHOP-318, must confirm that it supports the intended checkout verification.
Define the receiving responsibility around a decision: inspect the handoff evidence, identify the tests it enables, and accept a test window or record the remaining blocker. Shared QA ownership works better when those boundaries are visible. A coordinator may arrange the review while another tester performs it, but neither should assume the other has accepted the candidate.
Use the downstream work item's assignee according to the team's convention and record any separate receiver or coordinator in maintained work-item context. If testing needs independently tracked scope, capacity or actions, a linked testing item may be useful. Do not add duplicate work merely to list another name. Naming two responsibilities does not require assuming that Jira provides two default assignees or a built-in QA Owner field.
Leon should make acceptance specific. In the fictional callback example, he might accept contract review while leaving execution blocked until the candidate is available. Once execution can begin, he identifies the affected scenarios and the environment they require. Unrelated checkout checks may continue if their prerequisites and results remain valid.
The outcome is an acknowledged receiving action, not a claim that testing passed. Neither accepting a handoff nor assigning a tester grants release approval. If the receiver lacks capacity or cannot make the required decision, record that constraint and ask the agreed delivery or QA lead to resolve it before treating the dependency as ready.
A work-item status is a workflow signal, not a substitute for the evidence another team needs. Done on PAY-214 may describe completion of that item's agreed work. It does not independently establish that SHOP-318 passed or that Leon can test the intended candidate.
Agree on ready for the specified testing activity. For execution against a deployed change, the receiving tester should be able to establish:
Keep these references in controlled, maintained locations. “Latest staging build” can become ambiguous after another deployment. A successful earlier run can describe a different contract or candidate. Require enough identity and context to decide whether the evidence applies now, rather than attaching a screenshot with no build or expected result.
For the callback handoff, Mira supplies the candidate and contract references. Leon compares them with SHOP-318's expected checkout behavior and records whether the affected verification can start. If the contract changed after test design, review the affected expectations before treating the old baseline as current. The guidance on developer-to-QA handover readiness expands this intake agreement around candidate identity, receiving ownership and missing context.
Check evidence access as the receiving team, not only as an administrator. Creating a work-item link does not grant visibility of a restricted work item or its evidence, and it does not grant access to a separate build, document or test repository. Browse access, work-item security and the evidence location's own controls still apply. Attachment creation is also separately permission-controlled; a link is not an attachment-permission grant.
If Leon cannot open the contract or candidate record, keep the access gap visible and give an authorized owner the next action. Request the minimum approved access, or agree on an approved evidence location that provides the needed information without exposing restricted material. Do not copy passwords, tokens or protected customer data into another project's description, and do not export evidence merely to bypass its controls.
The readiness outcome can remain blocked while access is resolved. A reference that the receiving tester cannot inspect is not usable handoff proof.
Jira cross-project dependencies change as scope, people and candidates change. Assign a named coordinator to keep the agreement current, then choose a review rhythm appropriate to the delivery risk and the receiving test window. This cadence is a team convention, not a native Jira role, a prescribed SLA or a schedule created by linking work items.
Record the next review with an unambiguous time and time zone, the people needed, and who resolves an overdue or disputed action. The coordinator should leave each review with a readiness decision or an unresolved reason, an action owner and the next review point. They coordinate the evidence and escalation; they do not inherit authority to waive a security restriction or approve a release.
Do not wait for the regular review when a material assumption changes. Recheck after a contract or acceptance-criteria revision, a replacement build, an environment change, an ownership handoff, lost evidence access, or a delivery change that affects the agreed test window. Ask which earlier readiness decisions and results remain applicable.
A link alone should not be treated as status synchronization. Atlassian documents separately configured automation for updating linked work items when another item's status changes. If your site uses such rules, inspect their intended behavior separately. A propagated status still cannot establish that the receiving tester verified the candidate. Native link display also does not supply a critical-path calculation or a resource plan.
The compact register below illustrates an unresolved handoff after a review. It is a proposed coordination record, not actual Jira output or evidence of executed tests. Nia is the fictional coordinator and must record the next agreed review point with Mira and Leon.
Work Item | Current Handoff Decision | Named Next Action |
|---|---|---|
PAY-214 | Candidate and contract evidence still required for the receiving checks | Mira supplies identifiable, approved references and confirms the unblock condition |
SHOP-318 | Callback execution remains blocked pending evidence review | Leon verifies access and applicability, then accepts the affected test scope or records the remaining gap |
Use one blocked cross-project flow to establish this agreement before expanding the process. Ask the receiving tester to record a decision that another teammate can act on: ready for a defined scope, or blocked for a named reason with an owner and next review. If that decision still requires reconstructing a private conversation, improve the handoff record before adding more links.
A tester reviewing a Jira issue may need a fresh smoke run without opening GitLab and choosing pipeline parameters. A manually triggered Jira Cloud…
A scheduled QA flow stops updating release-readiness notes. Some work items may already have changed, others may still be waiting, and the last visible…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
