DACI in Jira: Give Every Decision a Clear Owner

A Jira issue can collect a long discussion without getting any closer to a decision. Engineering has one recommendation, support has another, and the product owner is waiting for someone to bring the options together. Everyone is participating, but nobody knows who should make the call.

DACI gives that conversation a structure. It identifies who moves the decision forward, who decides, whose expertise matters and who needs the outcome. In this guide, we will use a fictional customer portal team to work through a notification delivery decision and record the roles in Power Pack for Jira.

Understand the four DACI roles

DACI stands for Driver, Approver, Contributors and Informed. Atlassian's DACI play describes the Driver as the person who organizes the decision process and the Approver as the single person who makes the choice. Contributors provide expertise; informed participants receive the outcome. The source is linked below.

Keep the driver and approver distinct in your conversation. Coordinating the work does not automatically give someone the final decision. Likewise, choosing the outcome does not mean the approver must personally gather every piece of evidence.

Choose a question that needs a decision

Our fictional portal lets customers follow updates to their support requests. The team must choose how routine status notifications reach customers in the next release. They are considering immediate email, a daily digest and an inbox inside the portal.

Maya, the product owner, wants fewer distracting emails. Leo, the engineer, is concerned about adding a second notification system. Sam, the support lead, worries that customers will miss progress updates. Priya, the tester, needs a settled approach before designing the release checks.

Write the question on the relevant Jira issue: “How should we deliver routine support-request updates in the first portal release?” That wording gives the discussion a boundary. It covers routine status changes; it does not decide the behaviour of password resets, urgent security notices or every future communication channel.

Add a target decision date in the issue description using the team's normal process. In this example, the answer is needed before the next planning session. That date is a coordination agreement, not a promise that the matrix will send reminders or enforce a deadline.

Assign roles around the actual uncertainty

The team chooses Leo as driver because he can assemble the implementation options and identify missing technical evidence. Maya is the approver because the release tradeoff sits within her agreed product authority. Sam contributes customer-support context. Priya contributes testability and failure scenarios. Elena, who prepares customer communications, needs the final outcome.

Before entering these assignments, ask whether each person can fulfil the role. Leo needs time to compare the options. Maya needs to be available before planning. Sam and Priya need specific questions, rather than an open invitation to comment indefinitely.

If two people both believe they have final authority, settle that boundary before declaring the matrix complete. Perhaps the question combines a product choice with a separate budget decision. Split those decisions when they genuinely require different approvers. Adding another A to avoid the conversation leaves the underlying uncertainty intact.

Give contributors questions they can answer

Leo asks Sam to bring three recent examples where customers misunderstood a support-request update. He asks Priya to identify what can go wrong when several updates happen close together. He prepares a short technical comparison based on the team's existing system.

These are fictional inputs for the example, not measured product results. Their purpose is to show what useful contribution looks like. Each input connects a person's expertise to the decision being made.

The team agrees to assess the options against three questions: can customers notice useful progress, can the team support the approach with its current capacity, and can the release be tested convincingly? They write these questions alongside the options in the Jira issue so that everyone evaluates the same problem.

Avoid pretending that every consideration can be reduced to a precise score. A table can organize the conversation without producing a mathematically correct answer. If an estimate is uncertain, name the uncertainty and decide whether further investigation would change the choice.

Compare options before asking for a choice

Here is the team's working comparison. These observations belong to our illustrative portal, where email delivery already exists and an in-portal inbox would be new work.

Sam's examples suggest that customers value a prompt update when a request meaningfully changes. Priya points out that repeated edits could generate confusing duplicate messages unless the behaviour is defined. Leo explains that a digest requires additional scheduling and grouping work in this particular system.

Maya now has a concrete tradeoff to judge. She chooses immediate email for meaningful status changes in the first release, with duplicate handling specified in the delivery tickets. Minor internal edits will not generate customer notifications. The team will revisit a digest if customer feedback shows that useful updates still arrive too frequently.

That outcome is deliberately more precise than “use email.” It tells implementation, testing and support what the choice means. It also records the circumstance that could make the team reconsider.

Build the DACI matrix in Power Pack

Open Power Pack on the Jira issue and choose the RACI / DACI Matrix tool. Set the Model selector to DACI. The matrix then uses D, A, C and I for its available roles.

Start with the roster and add the people involved in the decision. Power Pack supports Jira user search and external participant entries. An external entry can represent a person in the matrix; it does not create an account or give that person access to the Jira issue.

In the deliverables view, add a row for the decision question. Although the interface uses deliverables as its row structure, a clearly named decision works well for this DACI example. Keep unrelated implementation tasks out of this first row so that the assignment remains easy to interpret.

Move to the matrix and assign Leo D, Maya A, Sam and Priya C, and Elena I. Clicking a cell cycles through the available roles. Focused cells also support the role-letter shortcuts shown in the interface.

Review the row indicators. Power Pack identifies missing approvers, multiple approvers and rows that need a driver. Those checks help you spot an incomplete role pattern. They cannot tell whether Maya has the organizational authority to decide or whether Leo has actually gathered enough evidence.

Check the save indicator before leaving the issue. If the tool reports a local or offline state, do not assume the latest assignments are already available to teammates. The useful agreement is the version people can find and discuss together.

Close the discussion with a usable outcome

A role matrix does not contain the whole decision. Record the selected approach, reasoning and important consequences in the issue description or Power Pack's Decision Log. Include the options that were seriously considered so that another teammate can understand the choice later.

Leo then shares a concise outcome with Elena through the team's normal communication process. The update says what will ship, which messages are included, what remains outside scope and where to find the implementation work. Marking Elena I in a matrix does not send that message.

Create or update the necessary Jira delivery tickets through your normal workflow. For this example, those tickets cover meaningful status-change detection, duplicate handling and verification. A DACI assignment records a role in the decision; it does not automatically change a Jira assignee or transition an issue.

Keep the framework proportionate

Use DACI when a real choice is stalled by unclear participation or authority. A routine implementation detail that an engineer can already decide may need only a short note. Adding a full matrix to every small choice can make the process harder to maintain.

Revisit assignments when the question changes. If the portal team later considers a paid notification provider, a different person may need to approve spending. The original product decision does not silently expand to cover that new authority.

Choose one unresolved question in your current Jira work. Give it a clear boundary, agree a driver and one approver, and identify the specific input required. Use Power Pack to keep those roles visible beside the issue, then record and communicate the decision when it is made.

• Atlassian Team Playbook: DACI Decision-Making Framework