An invoice-export story has an assignee, yet testing stalls. The QA specialist needs an administrator account, the engineer assumes someone else maintains the fixture, and an existing test still expects the old permission rule. Moving the story to a QA status would leave those questions unanswered.
QA roles and responsibilities in Jira become useful when they identify who performs each activity, who owns its bounded decision, and what evidence the team needs. A RACI matrix can record that agreement across test design, exploratory testing, test data and maintenance. Jira then tracks the actual work. The matrix should support collaboration throughout the Sprint rather than create another developer-to-QA handover.
Scrum defines the accountabilities of Developers, Product Owner and Scrum Master. Developers include the people creating any aspect of a usable Increment, not only people writing application code. A testing specialist contributing to that Increment can be a Developer in Scrum while retaining a QA job title. The team collectively needs the necessary skills; every individual need not have the same specialty.
The Scrum Guide makes Developers accountable for instilling quality by adhering to a Definition of Done. The whole Scrum Team is accountable for creating a valuable, useful Increment. Assigning someone test-design work does not make that person solely responsible for product quality or excuse other Developers from checking their work.
The Product Owner is accountable for product value and effective Product Backlog management, including work delegated to others. That supports involving the Product Owner when expected behavior or backlog ordering is unclear. It does not make the Product Owner a universal approver of every test result, technical decision or release.
A RACI matrix is an optional coordination agreement layered onto this framework. It cannot replace those accountabilities, impose a separate testing hierarchy inside the Scrum Team, or make unfinished work satisfy the Definition of Done. Work that falls below that definition cannot be treated as part of an Increment merely because a nominated approver accepts it.
RACI describes participation in a specific activity or deliverable. Use the letters to distinguish work from decision authority:
Atlassian's RACI guidance recommends one accountable individual per task and allows multiple responsible contributors. Use that as the convention for this matrix. It is not a universal Scrum rule: collective Scrum accountability still applies. The same person can be both responsible and accountable for a bounded activity when that arrangement suits the work and any required independent review.
Write the decision boundary beside each activity. A test-design steward might resolve whether the proposed checks address the agreed risks, but cannot independently change the product's access policy. A fixture custodian might accept a dataset as ready, but cannot authorize copying protected production data without the required approval.
If an activity needs unrelated decisions, split it. “Own testing” conceals design, execution, data access, maintenance and product interpretation. A person cannot meaningfully accept that assignment without knowing which decisions it includes, what output is expected and whether they have the capacity to do it.
The following matrix is illustrative, not a prescribed Scrum staffing model. QA specialist, fixture engineer and automation contributor describe skills or local responsibilities. In this example, they contribute as Developers. Stewards are nominated by the team for bounded coordination and review, not appointed as managers of other Developers.
Activity | Responsible (R) | Accountable (A) | Consulted (C) | Informed (I) |
|---|---|---|---|---|
Design tests for a changed flow | QA specialist and feature engineer | Design steward | Product Owner; domain specialist | Other affected Developers |
Conduct an exploratory session | Tester pair | Session lead | Feature engineer; Product Owner for ambiguity | Affected Developers |
Prepare and reset approved test data | Fixture engineer and QA specialist | Fixture custodian | Environment owner; privacy or security owner as needed | Session and run owners |
Maintain reusable test cases | Case maintainer | Product-area test steward | Product Owner; feature engineer | Run owners |
Maintain automated checks | Automation contributor | Suite maintainer | QA specialist; feature engineer | Run owners |
Clarify a product rule and update its backlog item | Product Owner or delegated analyst | Product Owner | QA specialist; feature engineer | Scrum Team |
Replace role placeholders with named people before using the matrix. A small team may nominate the same person for design stewardship and case maintenance. Record a backup or reassignment trigger for responsibilities that must continue during absence. Someone listed as consulted should know which question requires their input, rather than receive every testing discussion.
Give each row an observable output. Test design can identify risks, scenarios and expected results. An exploratory session can retain its objective, findings and unanswered questions. Data preparation should produce a usable starting state and reset instructions. Maintenance should produce reviewed changes linked to the requirement that triggered them.
The accountable person checks that the agreed activity has an outcome or a visible unresolved limitation. They do not certify that all defects have been found. Separate any organizational release authority or mandatory security approval from this activity matrix instead of quietly assigning it to the QA specialist.
The matrix describes a continuing agreement. A Jira work item describes a particular change or action. Connect them through an accessible reference and enough local context that someone can identify the next action without reconstructing a discussion.
Agree whether Assignee means the person performing the current action or a coordinating owner who remains assigned while others contribute. Either convention can work, but an assignment alone does not identify every responsible contributor, consulted expert and decision owner.
Keep a reference to the maintained matrix in the work item's context. Atlassian describes documenting RACI in Confluence and connecting it to Jira work; a maintained external document is another process choice. Confirm that the people doing the work can access the referenced agreement.
For an activity that needs separate tracking, record its intended output, responsible contributor, accountable decision owner and any consultation trigger. These can be clearly labeled parts of the description. They are proposed recording conventions, not universal built-in Jira fields.
Use subtasks or linked work items when activities need independently visible ownership, blockers or completion evidence. For example, fixture repair and case maintenance may proceed in parallel. In company-managed Jira Cloud, subtasks must be enabled and included in the relevant work type scheme; linking also depends on configuration and permissions. Avoid creating separate tickets merely to reproduce every matrix cell. Extra work items introduce coordination overhead and must remain aligned with the original requirement.
The person assigned to run a test this Sprint need not maintain that test indefinitely. Changing the story's assignee should not silently transfer ownership of the reusable case or dataset. Keep those continuing responsibilities in the maintained agreement or suitable configured metadata.
For Jira Cloud company-managed permission schemes, Atlassian distinguishes permission to change Assignee, permission to be an assignable user, and permission to transition work. A person named in the matrix may still lack the technical access needed to carry out the agreement. Resolve that mismatch with the administrator rather than relying on someone else's account.
Workflow configuration can reinforce selected rules. Conditions can restrict who may perform a transition; validators can check transition input before it occurs. A required-field check can establish that a value exists, but cannot establish that an exploratory session answered its questions or that a dataset matches the intended scenario.
Check the actual deployment and project configuration. Team-managed Jira Cloud work uses its own roles and available workflow rules; do not assume a company-managed configuration recipe applies unchanged. Current Atlassian documentation may call projects spaces and issues work items. The local configuration still determines which controls the team can use.
If reporting needs justify dedicated ownership fields, ask the administrator to configure appropriate fields and document their meaning. A user-picker field labeled Activity Owner is a customization, not a native RACI model. A Marketplace app may offer a different model, but its capabilities, permissions and suitability require separate verification. Adding fields or an app does not decide who has business authority.
Test-data ownership needs more detail than “QA provides accounts.” Agree who defines the required business states, who maintains the fixture or loader, who controls environment access, and who can approve handling protected information. The fixture custodian coordinates readiness within those boundaries; the role does not replace security or privacy authority.
Record a dataset reference, required roles and starting states, compatibility assumptions, reset method and recovery owner. A reset restores an agreed state; a refresh changes the dataset definition and may require review of affected tests. The guidance on safe, repeatable QA data develops those contracts, isolation and reset decisions beyond the ownership matrix.
Case maintenance needs a similarly durable home. When an acceptance criterion changes, identify who assesses the affected cases, who updates them and who reviews the resulting expectations. Do not wait for the next executor to discover the disagreement during a run. Keep the maintainer visible even when execution rotates among teammates. The guidance on test repository ownership explains this separation between ongoing maintenance and run assignments.
Sherlock Test Management's current product documentation describes source-linked cases in a human-approved, versioned baseline, with changed requirements flagging affected cases and prompting proposed edits. A nominated maintainer can assess the change while the agreed reviewer checks the proposal before acceptance. Its reviewed baseline workflow supports those responsibilities; it does not choose the team's RACI decision rights. Completed runs remain attached to the baseline version they executed, so updating today's expectation need not be confused with what an earlier run tested. These are app-level capabilities, not native Jira fields or evidence of autonomous application execution.
Consider an illustrative story, BILL-427, restricting invoice exports to billing administrators. The names, identifier and workflow below are examples, not a customer case or a tested Jira configuration. Ada is the QA specialist, Ben is the feature engineer and fixture custodian, and Chen is the Product Owner. Ada also maintains the affected reusable cases.
During test design, Ada finds that an older case expects a reporting analyst to export invoices. Chen confirms the new intended rule and updates the backlog item's description. That product decision gives the test designers an expected result; neither Ben's implementation nor the old test should settle the rule by default.
Exploration then stops because the supposed administrator fixture has only the analyst role. Ada records the blocked check and the observed account state. Ben repairs and verifies the fixture under the approved data process. The blocked attempt is not relabeled as a product failure or a pass. Once the starting state is valid, testing can distinguish an access-control defect from a setup problem.
Meanwhile, Ada updates the reusable case and asks the nominated test steward to review its coverage and expected results. Ben remains involved in the technical checks. Separate tracked actions can make fixture repair and case maintenance visible without moving the whole story repeatedly between developer and QA ownership.
When the team disputes an assignment, use a bounded resolution procedure:
The Scrum Master can help the team address an impediment or clarify an ineffective agreement. That does not make the Scrum Master the default approver of technical test design. Likewise, a testing steward cannot waive the Definition of Done because a release date is approaching. Decisions outside the activity's authority must reach the authorized owner, with the unresolved risk visible.
Review ownership when requirements, personnel, test tooling or environment responsibilities change. A role placeholder can remain unchanged while the person who understood its decisions has left. Ask the current contributors whether they recognize the work and have accepted it, rather than treating an old matrix as proof of ownership.
Look for responsibilities with no capable performer, an accountable person who cannot make the necessary decision, or consulted people who have become mandatory approvers without an explicit reason. Remove steps that produce no useful decision or evidence. Preserve necessary independent reviews and organizational controls rather than optimizing them away to make the matrix look simpler.
For the next story, choose one recurring ambiguity: test design, exploration, data readiness or maintenance. Name the people doing the work, the bounded decision owner and the output another teammate can inspect. Then make that agreement visible alongside the Jira action. Expand the matrix only when it resolves another concrete ownership problem.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
