Review your team's Jira backlog from start to finish

A complete walkthrough — see what the team can work on, improve weak stories, approve targeted Jira updates, and produce a stand-up summary without opening a browser.

Mode: tracker-authoritative. This tutorial assumes Jira holds the team’s real backlog. If docs/product/ is canonical and Jira is only for reporting, use repo-first projection instead.

By the end of this tutorial, you will have followed a complete Atlas team workflow: seen the whole backlog, identified what is ready, improved three stories, applied two approved Jira updates, and produced a stand-up summary — all from a single conversation.

Time: 30 minutes. Starts read-only — Jira is not changed until step 10.

Prerequisites: atlassian pack installed; Jira credentials (API token, or SSO — see Authenticate with SSO cookies); read access to APP and API projects; edit access for step 10.

Stage 1 — See the work

Step 1: Request the whole team backlog

Say exactly this, or something close:

Step 2: Respond to the scope clarification (if it appears)

The agent may ask one compact question when the team scope is ambiguous:

Pick the one that matches your team’s setup. If neither applies, say so — the agent will ask for a JQL filter or project list instead.

Step 3: Read the scope and completeness header

Before any grouped sections, the agent shows you what it searched and whether the result is complete.

Checkpoint: If the numbers look wrong — too few issues, wrong projects — stop here. Tell the agent what the correct scope should be before reading the grouped sections. Asking for corrections now is cheaper than reviewing the wrong backlog.

Step 4: Read the grouped result

After the scope header, the agent groups the 184 issues:

Group	Count	What it means
Ready to pull	17	In scope, no blocker, enough definition to begin
Needs story work	26	Open, but missing information the team needs to start
Blocked	8	Known unresolved dependency or decision
In progress	11	Currently being worked on
Other open work	122	Open but not in the categories above

Step 5: Review the recommended candidates

The agent recommends five items for the team to discuss next:

API-104 — Rate-limit response should include Retry-After header
APP-206 — User cannot reset password when SSO is enabled
APP-312 — Session timeout on mobile
APP-298 — Search index rebuild throttle
API-117 — Deprecate v1 auth endpoint

Checkpoint: Do these candidates reflect your team’s actual priorities? If not, tell the agent to filter by assignee, label, or component before moving on.

Stage 2 — Improve weak stories

Step 6: Request story improvements

Step 7: Understand the draft output

For each of the 26 items, the agent produces a structured analysis. Here is the output for APP-206:

APP-206 · User cannot reset password when SSO is enabled

Why not actionable: Fails the acceptance-criteria test — the description covers the happy path but does not specify what happens when the SSO provider is unreachable or returns an error. Engineering cannot begin without knowing whether to show a fallback or block the reset.

Proposed description: When a user attempts to reset their password and their account is SSO-enabled:

If the SSO provider is reachable: redirect to the SSO provider’s reset flow.
If the SSO provider is unreachable or returns an error: display “Your account uses single sign-on. Contact your IT administrator to reset your password.” Do not allow direct password reset as a fallback.
Log the provider error for the ops team.

Proposed acceptance criteria:

Given SSO-enabled user requests password reset, when SSO provider is reachable, then user is redirected to SSO provider reset flow
Given SSO-enabled user requests password reset, when SSO provider is unreachable, then user sees the contact-IT message and cannot set a password directly
Given SSO provider returns an error, then the error is logged with provider name and HTTP status

Unresolved question: Should the system allow a temporary bypass for locked-out SSO admins? Needs product owner decision.

Expected readiness after draft: APP-206 would pass the readiness bar once the product owner answers the bypass question.

Jira was not changed by this run.

Step 8: Work through the unresolved questions

Some issues have questions only the product owner can answer. APP-206 has one. You have two options:

Answer it now: Tell the agent the answer. It will update the draft accordingly. Still read-only — nothing goes to Jira.
Leave it open: The draft is preserved. APP-206 stays in “Needs story work” even after the other changes are applied. You can revisit it later.

API-104 · Rate-limit response should include Retry-After header

Why not actionable: ACs mention the header but do not specify the format (seconds vs HTTP date), the value source (fixed vs dynamic), or what clients should do when the header is absent.

Proposed acceptance criteria (additions):

Given a client exceeds the rate limit, when the API returns 429, then the response includes Retry-After: <integer seconds>
Given the token-bucket drain time is known, when 429 is returned, then Retry-After value equals ceil(drain_seconds)
Given drain time is unavailable, when 429 is returned, then Retry-After value is 30
Given any 429 response, then body contains {“error”: “rate_limited”, “retry_after_seconds”: <integer>}

Unresolved question: None.

Expected readiness after draft: API-104 would reach Ready to pull immediately after the draft is accepted.

Jira was not changed by this run.

Step 9: Select which drafts to approve

Review the drafts for APP-206, APP-219, and API-104. Decide which ones you want written to Jira.

Checkpoint: You are still read-only. Nothing has changed in Jira. This is the last moment to adjust or discard any draft before you confirm writes in the next stage.

Stage 3 — Apply approved changes

Step 10: Request the exact writes

This is the first step that will change Jira.

Step 11: Review the write preview

Before anything is written, the agent shows you the exact payload:

Issues: APP-206, APP-219, API-104
Fields: description, acceptance criteria
Protected (will not change): status · assignee · sprint · priority · labels
Total writes: 3

Issue	Field	Current value	Proposed value
APP-206	description	“User cannot reset password when SSO is enabled”	[full proposed description above]
APP-206	acceptance criteria	(none)	[3 ACs above]
APP-219	description	“Export to CSV drops custom field values”	[full proposed description]
APP-219	acceptance criteria	(none)	[4 ACs]
API-104	description	[current text]	[full proposed description]
API-104	acceptance criteria	[partial existing ACs]	[4 ACs above]

Type confirm to write these changes, or cancel to stop.

Checkpoint: Read the proposed values for each field. If any proposed value is wrong, say “cancel” and tell the agent what to change. Confirming is permanent.

Step 12: Confirm the writes

Type confirm to proceed.

Step 13: Handle the partial failure

APP-219 fails because your token has reporter-only access. APP-206 and API-104 succeed.

This is a normal outcome. Two of three writes succeeded. The third has a clear recovery path.

Step 14: Request the stand-up summary

Step 15: Read the stand-up summary

The agent produces a read-only summary from the backlog data you reviewed:

Step 16: Review the Confluence draft

The agent also produces a Confluence-ready draft:

Checkpoint: This is read-only and unpublished. Review the draft. If you want to adjust the tone, scope, or emphasis, tell the agent. Only say “publish” when the content is exactly right.

Step 17: Stop before publishing

For this tutorial, stop here. Publishing to Confluence is a separate approved action.

When you are ready to publish in a real session, say: “Publish the Confluence draft to the Atlas space.”

The agent will show you the exact page title, space, and content before writing anything.

What you learned

The whole-team backlog workflow starts read-only; scope and completeness are disclosed before any grouped data.
“Ready to pull” is not Jira To Do — it means in scope, unblocked, and defined.
Story improvements are draft-only until you explicitly approve writes.
The exact fields, current values, and proposed values are shown before any write.
Protected fields — status, assignee, sprint, priority, labels — are never changed.
Partial write failures have a clear recovery path; the session preserves the approved draft.
Confluence publishing requires a separate explicit approval.

What to do next

I want to…	Go to
Do specific tasks without the full journey	Work with Jira from a conversation
See exact skill contracts and limits	Atlassian skills reference
Understand how the workflows compose	How the Atlassian pack works
See the journey as a visual storyboard	Atlassian journey
Return to the pack overview	Atlassian pack