AI Backlog Management: Propose, Don't Auto-Prioritize

Search “ai backlog management” and the first page is a hygiene manual. Find the duplicates. Flag the tickets nobody has touched in ninety days. Fill in the missing acceptance criteria and story points. Score everything with RICE or MoSCoW and let the tool “automatically adjust priorities as business conditions change”. Every page ends with the same disclaimer, that AI assists and the product owner decides, and not one of them says what deciding looks like, where the decision is recorded, or who is on the hook when the agent’s suggestion was wrong.

Search “ai backlog for jira” and the picture is thinner. The top result is a Marketplace app whose listing now reads “This app has been archived”. Atlassian’s own Rovo features and Linear’s AI do real work inside the trackers, and the pages that mention them do so in passing, with no account of where a third-party agent fits beside them.

This post is the version for an engineering manager who owns a backlog in Jira or Linear and wants an agent to help without giving up the order. The worked example is a YAGNI Team, where the Agent that does this job is Bailey, the Product Manager.

What do AI backlog management tools actually do?

Three kinds of thing, and it helps to keep them apart.

Hygiene. Duplicate detection, stale-ticket flagging, missing estimates and acceptance criteria, label and priority cleanup. This is what most of the ranking pages mean by backlog management. One published case study describes an agent that read a backlog of 847 tickets and recommended closing or merging it down to 312, with a reasoning comment on each, and is honest that the product manager still made the final call. A 2025 empirical study of a Jira plug-in for duplicate detection found the same shape: in its interactive mode, where nothing changed without a user confirming it, precision was 100 percent, while its automatic mode produced false positives (arXiv 2507.10753, read October 2026).

The trackers’ own AI. As of October 2026, Atlassian’s Jira AI page describes Rovo breaking work down “into easily manageable tasks with just a click”, generating summaries and descriptions, and surfacing similar requests, on Premium and Enterprise plans. Linear’s AI page describes Triage Intelligence suggesting “assignees, teams, projects, labels, and related issues based on how your team already works”, and a Linear Agent that reads projects, issues, customer requests, docs, and code. Both are useful, both are inside the tool, and neither answers the question an engineering lead opens the backlog to answer on Monday morning.

Sequencing. What is next, for this team, this week, and why. This is the part the hygiene tools skip and the auto-prioritization tools get wrong, and it is the job an engineering manager actually wants help with. The rest of this post is about it.

Should an AI agent prioritize the backlog on its own?

The vendor pages say yes. “Let AI make the tough decisions.” Continuous optimization that “automatically adjusts priorities as business conditions and constraints change.” It is the wrong shape for an engineering team, for three reasons that have nothing to do with how good the model is.

Priority is a product-intent call. Whether the invoice export matters more than the coupon bug this week depends on a customer conversation, a contract, a hunch about the quarter. The tracker does not hold that context and the agent does not either. An agent that rewrites the order on its own is guessing at the why, and when it guesses wrong nobody finds out until the week is over.

An auto-prioritized backlog has no owner. The ranking pages end with “the product owner decides”, but a tool that reorders the backlog overnight has already decided. Accountability needs an act: a person read the suggestion and said yes. If the act is missing, so is the accountability.

A rewrite leaves no record. A reorder is a state; a proposal is an event. “Bailey proposed CHK-412 on Monday with these three reasons, and Priya accepted it” is a fact a manager can read in a month and learn from. “The priority field changed” is not.

The same consequence frame runs through human in the loop AI agents: decide what waits for a person by what the act does to the world, not by how confident the agent sounds. A proposal is reversible. A silent reorder of the team’s source of truth is not, because nobody saw it happen.

So the shape to ask any AI backlog tool for is this: the agent reads, ranks, and proposes; a named person accepts or declines; the tracker stays the team’s. On a YAGNI Team that is Bailey’s one job.

What does a good proposal look like?

A proposal is a small document written for a decision, and the decision is two verbs. On a YAGNI Team the proposal Bailey writes is the ticket’s spec, in a fixed shape so the later stages can read it:

Part of the proposal	What it holds	Why it is there
The problem and the outcome	What is wrong now and what is true when it is fixed	So the person can decide in a minute whether it is worth doing
Why now	The evidence from the tracker: the open ticket, its priority and age, the linked requests, what it blocks	So the ranking is checkable, not asserted
Done when	Three to six plain statements someone else could check	So Reeve’s plan, Proctor’s review, and Fletcher’s test plan read the same definition of done instead of re-deriving it from prose
Out of scope	What this ticket is not	So the build stays the size the person accepted
Open questions	What Bailey could not settle from the tracker and the repository	So the product-intent call is asked, not guessed

Before the proposal reaches a person, Bailey has read the Team’s backlog, ranked what is ready, and readiness-checked the rest. A ticket with no acceptance criteria is called not ready rather than proposed with made-up ones. Bailey also reads the repository in a read-only pass, so “why now” can say which module the change lands in, and it reads the Team’s Decisions, the ledger of product-intent calls already made, before it guesses at any.

The person’s verbs are “Start plan” and “Doesn’t need work”. A proposal always waits. Bailey never starts anything, and a proposal nobody touches closes on its own after three weeks rather than nagging forever. “Propose again” is a manager’s verb: it asks Bailey for a fresh set within the line’s settings, withdrawing its own untouched proposals first and recording why, so running it again is honest instead of the same three tickets reappearing.

How does this work with Jira and Linear?

The backlog is what a Team works from, and attachment is the signal. A Team attaches a Linear team, project, or saved view, or a Jira project, epic, saved filter, or JQL query. A Team that attaches nothing while the workspace syncs a tracker has the whole tracker in view, and Bailey picks from it by the Team’s Responsibilities, saying why each ticket is this Team’s. A Team with no tracker in reach works from its Responsibilities alone.

A saved view, a saved filter, or a JQL query is a selection the tracker owns, so Bailey reads it live on every turn, as the Team, and honours the tracker’s order only where the tracker states one (a Jira ORDER BY counts; a Linear view narrows the backlog without ordering it). A selection that cannot be read is named in the run and left out, never widened to the whole workspace. A backlog whose tracker is still on its first sync is held rather than read as empty, so Bailey never proposes “confirm the backlog is empty” against a tracker that is still arriving. A Jira project is dark to everyone in YAGNI until an admin opens it by attaching it to a Team, an audited, reversible act under Connections.

What gets written back is deliberately small until a person decides. The proposal lives on the ticket’s case file in YAGNI, not as edits to the Jira or Linear issue, so the tracker’s order and fields are untouched by a proposal nobody accepted. When a proposal needs an issue that does not exist, Bailey drafts it and the draft waits for a person; a tracker that fills itself with agent-written tickets is a tracker nobody trusts. Once a ticket is accepted and moving, each step writes back through the tracker’s own objects: the plan as a comment, the status at build, the pull request at review, and Done only when a person merges. What a Jira AI agent should do with an engineering ticket has the full write-back table.

This sits beside Rovo and Linear’s AI, not in front of them. Breaking an epic into child items or letting Linear suggest the assignee still leaves “what is next, and why” to a person. Bailey’s proposal is the answer to that question, written down, with the person’s click beside it.

What does Monday morning look like?

A Checkout Team with four engineers, Bailey’s propose line set to run weekday mornings against the Linear project “Checkout”, three proposals per run, supervised by Priya, the Team’s owner. The run reads 61 open tickets, ranks the 14 that are ready, and proposes:

Proposal	Why now, per Bailey	Priya’s click
Reject a discount code after its end date, with a message (CHK-412)	Urgent in Linear for nine days, three linked customer requests, blocks nothing, the validation module already has the hook; Done when: five statements	Start plan, 9:14
Invoice export to CSV (CHK-418)	High priority, the longest-open ready ticket on the project, the finance team asked twice in the linked thread; one open question on date format	Doesn’t need work, with a note: “wait for the tax decision”
Retry refund webhooks on a 5xx from the processor (CHK-420)	Medium priority, but four failed webhooks in the last week’s logs linked from the ticket; Done when: four statements	Left open

CHK-412 moves to Plan, where Reeve plans it for Priya to approve. CHK-418 goes back to the backlog with Priya’s reason attached to the proposal, and that reason is now something Bailey reads next time: “wait for the tax decision” is a product-intent call, and once Priya records it in Decisions, no Agent on the Team has to ask again. CHK-420 waits; if nobody touches it in three weeks it closes on its own, and Bailey may propose it again with fresh evidence.

Nothing in Linear changed except CHK-412, now in progress with a plan comment on it. The order of the other 60 tickets is exactly what the team left it. That is the difference between a proposal and an auto-prioritized backlog, and the reason a team can let the agent run every morning.

What does the record show afterward?

The proposal, the evidence, and the click, on the ticket’s case file, with the time. Tracking engineering progress without a project manager argues that status should come from the record; the proposal is the first entry in that record for every ticket.

Beside the propose line on the Team page sits its track record: accepted as proposed, edited, sent back, over time. “22 of the last 25 accepted as proposed” is the sentence a manager reads before trusting the line more, and misses stay on it. A declined proposal with a reason is a correction, and corrections become candidate Playbook rules the Team adopts or dismisses: “finance-facing exports wait for the tax decision” is a rule after Priya has said it once. That is how the line gets better at this team’s judgment, and the claim is only sayable because the track record is beside it.

And the cost is on the record too. Every run lands on the case file with what it cost, and Usage adds it up per Agent, broken out by the job that spent it, so “what does the propose line cost us a month” is a number an admin can read rather than estimate. There are no seats. Bailey’s runs are metered on one rate card, on vetted US-hosted open-weight models at 60% or more under comparable frontier API rates.

Grooming tool, the tracker’s own AI, or an Agent that proposes?

The ranking pages compare grooming tools against each other. The comparison an engineering manager needs is across the three kinds.

	Backlog grooming tool	Jira Rovo or Linear AI	YAGNI Team (Bailey)
What it does to the backlog	Flags duplicates, stale tickets, missing fields; some reorder priority on their own	Breaks work down, summarizes, suggests assignees, labels, and related issues	Ranks what is ready and proposes the next ticket as a spec with the evidence
Who decides what is next	The tool, or nobody	A person, with better-filled fields	A named person: Start plan or Doesn’t need work
What changes in the tracker before a person acts	Often the priority field, labels, closures	Fields and child items a person triggers	Nothing; the proposal lives on the case file until accepted
The record	Reasoning comments, in the better tools	The tracker’s history	The proposal, the evidence, the click, the time, and what the run cost
What happens after accept	Nothing; the ticket is still a ticket	Nothing; the ticket is still a ticket	Reeve plans it, Wright builds it to a draft pull request, Proctor reviews, Fletcher (beta) tests, a person merges
Learning	None, or per-tool settings	The tracker’s own models	Corrections become Playbook rules; the track record sits beside the line
Pricing	Per seat per month, usually	Rovo credits on Premium and Enterprise plans; Linear by plan	No seats; metered per run on one rate card, shown on Usage

The honest read of the first column: the hygiene is real and a backlog of 847 tickets does need the duplicates found. Do that, with a tool that asks before it closes anything. Then notice that a clean backlog still does not say what is next.

Where does this leave the backlog?

In the tracker, owned by the team, in the order the team left it, with one agent reading it every morning and writing one small document per proposal that a named person accepts or declines in a minute. The proposal is the piece that turns a backlog into a decision with a record, and it is the piece none of the ranking pages describe.

YAGNI runs agent teams, managed like your engineering team. On each one, Bailey proposes the next ticket from the Team’s Jira or Linear backlog with the evidence for it, a person accepts it, and the same ticket moves through plan, build, review, and QA to a pull request a person merges. The agentic software development lifecycle walks those stages. See how Agent Teams work, or book 30 minutes to attach one of your Linear projects or Jira filters to a Team and read Bailey’s first three proposals before anything else happens. Bailey is one of six Agents; the guide to AI agents for software development covers what happens to a proposal after a person accepts it.