Choreography: the backlog that triages itself
AI sweeps through a volume of tickets the team would never cover by hand and lights up the suspects: duplicates, severity outside the curve, wrong team in the queue. You're still the one who confirms the ambiguous cases and decides the action.
Monday morning, and the Jira queue woke up with 340 new tickets, a mix of bugs, feature requests, and customer complaints forwarded by support. Among them, two tickets opened through different channels describe the same checkout error with different words, one of them marked "low" because whoever opened it didn't know the size of the damage. Nobody's going to read all 340 descriptions line by line before the 9 AM daily. This lesson's question is: who sweeps through that volume for you, and who confirms what shows up before it becomes this week's priority?
The firm receives notifications and summonses from different sources every week, each with its own deadline. AI groups the ones that seem to belong to the same case, suggests severity by the type of filing, and routes them to the responsible attorney. It marks as a "comfortable" deadline a summons whose text is dense and formal, without noticing that the real procedural deadline, counted from the publication date, is due in two days, not two weeks as the text suggested at first read. Trusting the suggested severity without checking the publication date nearly cost a missed deadline.
At the end of every review cycle, HR receives dozens of requests: promotion requests, climate complaints, benefits questions. AI groups similar requests, suggests priority for each, and routes them to the right analyst. It marks as "normal priority" a climate complaint that mentions, in passing, a specific manager's behavior, because the text is polite and doesn't use words like "harassment" or "abuse". Except this kind of discreet mention is exactly what usually precedes a formal complaint weeks later. Treating it as normal priority and leaving it in the common queue nearly let a signal slip through that should have gone straight to the people compliance team.
The product feedback board receives hundreds of requests a month, from support, sales, and research. AI groups similar requests, suggests which pain point is most recurring, and proposes roadmap priority. It marks as low priority a request that appears only three times in the text, because low volume usually means low impact. Except those three mentions come from the three biggest accounts in the base, each worth more than a hundred small customers combined. The priority AI suggested, looking only at mention volume, nearly hid the request that was worth the most money.
Every week, dozens of objections and discount requests arrive from sales to the pricing team. AI groups similar requests, suggests which objection is standard market practice and which falls outside policy, and routes what falls outside for manager approval. It marks as "within policy" a discount request that, combined with a hidden clause in that same customer's previous contract, actually blows through the ceiling agreed on the board. The request's text, in isolation, looked normal; only cross-referencing it with the customer's history reveals the problem. The suggested route nearly let through a discount that broke the quarter's agreement.
The operational incident dashboard receives complaints from several regions at once: delivery delay, damage, driver complaints. AI groups similar complaints, suggests severity, and routes them to the responsible region. It marks as low severity a set of delay complaints in a specific region, because each isolated complaint looks like a one-off traffic issue. Except together, these complaints point to a structural problem in that region's distribution center, which will get worse if nobody acts this week. Treating each isolated complaint as a one-off case nearly hid a structural problem behind everyday noise.
The internal reporting channel receives accounts from different areas all the time, most are process questions, but some are serious. AI groups similar reports, suggests severity, and routes them to the right person. It marks as low severity a report that uses cautious, indirect language, because the text has no alarm words. Except serious compliance reports tend to come exactly like that, cautious, because whoever reports fears retaliation. The severity AI suggested, calibrated only by tone, nearly classified as routine the kind of report that most needs fast attention.
Usability research generates dozens of friction reports every week, coming from recorded sessions, NPS, and support tickets. AI groups similar reports, suggests which friction is most recurring, and routes it to the design team responsible for that screen. It marks as low priority a set of complaints about the signup flow, because the absolute volume is small compared to other queues. Except this specific flow is every new customer's first contact, and every abandonment there costs a customer who never gets to know the product. The suggested priority, looking only at volume, nearly hid the friction that was costing the most revenue.
Every week, dozens of requests and market signals arrive for the strategy committee: a partnership request here, a competitor mention there, an analyst insight somewhere else. AI sweeps through everything, groups similar requests, suggests which ones deserve the board's attention this week and which can wait for the next cycle. It marks as "low urgency" a signal that a small competitor started copying your positioning, because the text sounds like ordinary market noise. Except that specific competitor already converted two of your customers last quarter, a data point only someone tracking the funnel closely would cross-reference. The route AI suggested nearly buried the right signal under the noise.
Whoa, anyone who's ever owned a ticket queue knows the feeling: the inbox never empties, and every day more arrives faster than any team can read. So, in practice, the team does what it can: looks at the most recent tickets, the loudest ones, the ones someone chased down in the hallway. The rest sits in the queue, waiting. Think with me: what if you could sweep through the whole queue, and the team only had to look closely at the cases that really call for judgment? That's exactly this lesson's choreography.
The core idea of this lesson. AI isn't the one who decides what matters in your backlog. It's the first triage: it groups duplicates, suggests severity, and points to which team something should go to, at a volume no team would cover reading ticket by ticket. But confirming the real severity, resolving the dispute over who owns the problem, and deciding the action, that stays with the team. And there's a real cost when the suggestion is wrong: wrong severity becomes wrong priority, and wrong route becomes lost trust between teams.
01What AI does well: dedupe, suggested severity, routing
Let's call it what it is. Any backlog's bottleneck was never a lack of intelligence, it was volume. Nobody has time to read 340 tickets line by line every Monday, so what's left is triage by sampling: the most recent ones, the loudest ones, the ones someone remembered to chase.
AI flips that math. You point it at the whole queue and ask it to do three things at once:
- Dedupe. Finding tickets that describe the same problem, even coming from different channels (one from Jira, one from Zendesk, one forwarded from support's WhatsApp) and with different words.
- Suggested severity. From the text and the system mentioned, proposing whether it looks critical, high, medium, or low, and explaining why it suggests that.
- Routing. Pointing to which team that ticket should go to, based on the component or system it mentions.
The real gain here is reach. You go from "we looked at the twenty most recent tickets" to "we went through all 340, and we have a short list of cases that need a human eye". Fair?
How the triage works, in practice:
02What stays the team's: confirm, resolve, and decide
Here's the part AI doesn't do, and it's the heart of triage. It grouped, suggested severity, and pointed to a route. And now? Now the team's work begins, and it's all judgment.
- Confirm the dedupe. Two tickets can look like the same problem in the text and actually be two different bugs that just happened to show up on the same screen. Merging them wrong hides the second problem behind the first. Someone on the team needs to take a close look before closing it as a duplicate.
- Confirm the real severity. AI reads the text and the system mentioned; it doesn't know the business impact behind it. A polite report with no alarm words can be the most serious of all, like the security report that "sounds similar to previous cases" and actually exposes another customer's data. Only whoever knows the system and the customer can weigh that.
- Resolve the ownership dispute. A ticket that mentions authentication and payment at the same time can be routed by AI to the wrong team, because the text leans more toward one side. Deciding whose problem it is, when two teams have a partial claim, is a conversation between people, not an automatic suggestion.
- Decide the action. Once confirmed, someone escalates it, prioritizes it in the next sprint, or explains it to the customer. AI doesn't close a ticket, doesn't change production priority on its own. Who decides, and answers for the decision, is the team.
Notice the design: AI narrows your search field, it doesn't replace the judgment of whoever knows the system. It turns "read everything" into "confirm what matters".
03The cost to name: wrong severity or route
Now the part I can't let slide, because it's where this choreography goes wrong if accepted without checking. AI suggests, and not every suggestion is right. That has a cost, and the cost has two faces.
The first face is the critical ticket labeled low priority. It happened in the vulnerability example: a "medium" suggested severity, accepted without checking, leaves a serious flaw waiting in the common queue for days, while the real problem stays exposed. The second face is the opposite: an alarm treated as urgent that actually wasn't, consuming the wrong team at the expense of a real priority left waiting.
Neither is the tool's fault. It's the cost of treating a suggestion as a verdict. That's why this choreography's rule: the team confirms before any severity or route becomes an action. The suggestion lights up the candidate; confirming is what turns a candidate into a real priority.
Learn more: why severity "sounds" wrong more often than it seems
AI calibrates severity mainly by the tone and vocabulary of the text: urgency words, mentions of critical systems, repeated terms. The problem is that people who open serious tickets don't always write with urgency, sometimes they write cautiously, especially when the subject is sensitive (security, customer data, an account the person isn't even sure how big it is). And people who open small tickets sometimes write in all caps. The result is that the text misleads in both directions, up and down. That's not a reason to discard the suggestion, it's a reason to know where it tends to be wrong: severity calibrated by tone alone needs a second read whenever the subject is sensitive by nature (security, personal data, a big customer), because that's exactly where cautious text looks most like routine.
04The choreography, step by step
Put it all together and it becomes a simple system, running every sprint turnover or even every day, depending on your queue's volume.
- AI triages. You feed it the whole queue and ask for dedupe, suggested severity with the reason written out, and a suggested route by the component mentioned. Output: a short list of cases needing a human eye, the rest follows the standard flow.
- The team confirms the ambiguous ones. Take the short list and look case by case: is the dedupe right, does the severity match the real impact, is the route the right team.
- The team decides the action. Once confirmed, the ticket becomes a sprint priority, an escalation, or a customer response. AI doesn't close anything on its own.
- The team logs the pattern. Every time the suggestion was wrong (merged what shouldn't be merged, underestimated severity, routed wrong), that becomes a note to calibrate the next triage, the same kind of source as the visible technical debt you'll see in the next lesson.
Notice that AI shows up in just one step, at the beginning. It expands the reach of whoever triages, it doesn't decide in place of whoever knows the system. Shall we?
05Where this fits
This choreography is the same quality gate logic you already saw in lesson 6.1, just applied to the backlog's entry point, not the code's exit point. There, the gate decided what passed before the deploy; here, human confirmation decides what becomes priority before entering the sprint. Same principle: AI operates the conveyor belt, the criteria that decides stays yours.
Do it now
Pick a real batch of tickets from your backlog, your real task or the last 30 opened in your queue. Ask AI to do the first sweep:
- Point out possible duplicates among them.
- Suggest the severity of each one, with the reason in one line.
- Suggest the responsible team or component for each one.
Now do your part, which is the part that matters: take the first five items on the list and classify each one as right route, right severity, or needed human correction. Count how many needed correction. That number is your calibration: it shows you how much the automatic triage gets right the first time, and why the team's confirmation isn't optional.
Practice
1. In the backlog triage choreography with AI, what's the correct role for AI?
2. AI suggested 'medium' severity for a technical vulnerability report, but investigating, the team discovers it exposes another customer's data. What does this show?
3. Why does the backlog triage choreography resemble the quality gate from lesson 6.1?
For the board
On the queuewith no scanning the team looks at whatever arrived last and whatever shouted loudest. The rest waits in the dark.
On the AI's roleit goes through the entire queue and returns a short list with a suggestion and a reason, ready for confirmation.
On severitycalibrated by the tone of the text it misleads in both directions. A sensitive subject always calls for a second read.
Thanks for the feedback. It helps sharpen the next lesson.