It's Thursday backlog review. The board shows four hundred open tickets, and the team spends the hour dragging the same thirty around the top of the list. A login bug from last spring moves up two places. A "quick win" that nobody has touched in a year moves down one. Everyone leaves feeling slightly behind, and the count goes up by six before Monday.
Nobody in that room is lazy. The problem is that the backlog is being sorted, not decided. If you want to clear an engineering backlog, re-ranking it won't do it. Reading every ticket once and putting it in one of three piles will: keep it, hand it off, or kill it.
The hand-off pile is where instinct goes wrong. You want to give an outside engineer the easy tickets. The evidence says hand off what's bounded and verifiable instead, and those aren't the same tickets.
Backlog triage is a single pass through every open ticket that ends in one of three decisions: keep it in-house, hand it off to an outside engineer, or kill it. A ticket goes in the hand-off pile only if it is bounded, verifiable and low-context, with a written done-condition and an in-house reviewer.
Key takeaways
A long backlog isn't a to-do list. It's a mix of real work, stale ideas and mislabelled noise, and adding effort to the mix doesn't separate it.
Ryan Singer put the cost plainly in Shape Up: "Backlogs are a big weight we don't need to carry." [C7] He also named the feeling from that Thursday meeting: "The growing pile gives us a feeling like we're always behind even though we're not." [C7] Basecamp's answer is to stop treating the pile as precious, because "Really important ideas will come back to you." [C8]
If working harder means starting more tickets at once, it makes things worse. Little's Law, in ProKanban's words: "the more items you have in progress at one time, the longer it takes to complete each item." [C9]
And you can't shortcut the sort with a filter. When Herzig, Just and Zeller manually examined more than 7,000 issue reports from five open-source projects, they found 33.8% of them misclassified [C1]. A ticket filed as a bug turned out to be a feature request, a documentation update or a refactoring [C1]. If a third of the labels in those trackers were wrong, your Jira labels aren't a triage tool either. Someone has to read the tickets.
Backlog triage, in this post, means one pass, one decision per ticket, three possible outcomes.
Keep is work that needs your team's context: the core domain, the high-context fixes, the architecture calls. It stays in-house and gets prioritised properly.
Hand off is work an outside engineer can finish and you can check. The next section has the test.
Kill is everything else. If nobody can say what done looks like and nobody would notice it gone, it's not backlog. It's an archive with a status field.
A short hand-off pile of well-shaped tickets beats a long one full of maybes.
Hand off tickets that are bounded, verifiable and low-context, with a written done-condition and an in-house reviewer. "Easy" isn't on the list, and that's deliberate.
GitHub's "good first issue" label is the closest public dataset I know of on easy tickets handed to outsiders. Tan, Zhou and Sun studied 9,368 of them across 816 popular projects [C2]. Their finding: "Compared to common issues, GFIs usually need more days to be solved." [C2] And "almost half of GFIs are not solved by newcomers." [C2] A follow-up study of 48,402 good first issues found that about 70% had expert participation [C10]. The easy ticket still cost a senior's attention. It just cost it in comment threads.
So the filter isn't how easy a ticket looks. It's whether someone outside can finish it and someone inside can tell that they did.
Bounded. DORA's guidance on small batches says features should "take no more than a few days to develop" and that "Any batch of code that takes longer than a week to complete and check is too big." [C3] Open edX wrote this down for its own contributor tickets: ideally no more than 3 hours for a developer who knows the process, no more than 10 files, and "doable immediately, without waiting for another change to be made." [C11] You don't need their numbers. You need numbers.
Verifiable. The ticket says what done looks like before work starts: the test that passes, the screen that renders, the endpoint that returns the right payload. We've covered writing short tasks that define the problem and "done" in our post on running async dev teams.
Low-context. Martin Fowler's advice for distributed teams was to split them along modules that are as loosely coupled as possible [C12]. A ticket that touches one module through a stable interface is a hand-off candidate. A ticket that needs someone to know why the billing service has three retry paths is not. Integrations look like easy hand-offs, but only a stable interface makes them one. That case is in the API and integration backlog nobody staffs.
Reviewed in-house. The good-first-issue research found that expert involvement correlates with newcomers' successful contributions [C10]. Budget that review time up front, and put the reviewer's name on the ticket.
The keep pile is the work where context is the job: core domain logic, fixes that need tribal knowledge, and architecture decisions.
Fred Brooks explained why in 1975: "Adding manpower to a late software project makes it later." [C13] His first reason was the time new programmers need to learn the project [C13]. His second was the extra communication overhead [C13]. Neither has gone away. Atlassian's 2025 State of DevEx survey covered 3,500 developers and managers in six countries [C14]. Half of the developers reported losing 10 or more hours a week [C14]. The top drain was "finding information (services, docs, APIs)". [C14] If the hard part of a ticket is finding information, an outsider will pay that cost on day one.
There's a sharper critique of handing work out at all. Jeff Gothelf argues that "Vendor business models dictate success as 'works as spec'ed' not 'met customer needs'". [C15] Fowler warns that offshore work "introduces extra costs and risks that may offset the rate differential." [C12] Both are right about high-context work. The sort's answer is to keep the work where writing the spec is the hard part, and hand off only the work where the spec is already written.
The kill pile is the biggest relief and the biggest risk. Several practitioners who've written about it picked an age.
At ProductPlan, Adrian Bryant sat down with the CTO and deleted every item not planned for a near-term sprint: "Over 600 items... gone." [C4] His rule: "I suggest deleting anything in your backlog that is older than six months." [C4] A Thoughtworks team facing 2,835 items dismissed stories that had been silent for more than a year [C5]. Alan Page suggests starting with "close every bug older than n months", then lowering n once nothing bad happens [C16]. Shape Up goes furthest: no grooming, and no carrying "scraps of old work over without first shaping and considering them as a new potential bet." [C17]
The counter-evidence is worth taking seriously. Khatoonabadi and colleagues studied 20 large open-source projects that adopted Stale bot, which closes inactive pull requests automatically [C6]. In the first few months after adoption, projects closed more pull requests, and the ones that were merged got reviewed faster [C6]. They also saw a considerable drop in active contributors [C6]. My reading: inside a company, the equivalent is the support lead who stops filing tickets because they keep disappearing.
Kill by decision, not by bot. Three habits keep the signal:
If an idea is important, it'll come back [C8]. Your job is to make sure the person who brings it back doesn't feel ignored.
The safest way to outsource development tasks is one at a time. Pick one ticket from the hand-off pile, write the done-condition, name the reviewer and send it. One task at a time keeps work-in-progress low [C9], and it shows you how an outside engineer handles your codebase before you commit to more.
To grade it, use the rubric from how to evaluate a dev subscription on one ticket, written before the work starts.
If you want yousource to take that first ticket, that's what Dev On Demand is for. One engineer is $3,495 a month, or $6,795 for two working in parallel. Work runs on a 3-day task cycle with daily async updates, and you sign off on each task before the next begins. We match you with an engineer the same business day, and your first task ships within 5 business days. If the engineer isn't right, we replace them within 5 business days at no charge. You can cancel any time with no notice period, and you own all the code, with IP assignment up front. "Start with one real task — judge the engineer before you subscribe."
This week, read the top fifty tickets and give each one a pile. Then hand off the first one that passes the test, and name who will review it.
Read every open ticket once and put it in one of three piles: keep in-house, hand off, or kill. Don't triage by label, because a manual study of more than 7,000 issue reports from five open-source projects found 33.8% misclassified. [C1] Re-ranking the list without deciding leaves it the same size.
Tickets that are bounded, verifiable and low-context, with a written done-condition and an in-house reviewer. DORA's guidance is that any batch of code that takes longer than a week to complete and check is too big. [C3] Keep core-domain, high-context and architecture work with your own team.
Not by default. In a study of 9,368 good first issues from 816 popular GitHub projects, those issues usually took more days to solve than common issues, and almost half were not solved by newcomers. [C2] In a larger follow-up study, about 70% of good first issues had expert participation. [C10]
Some practitioners do. Adrian Bryant of ProductPlan suggests deleting anything older than six months, and a Thoughtworks team dismissed stories that had been silent for more than a year. [C4] [C5] A study of 20 open-source projects found that automated stale-closing came with a considerable drop in active contributors. [C6] Export first, merge duplicates and leave a reopen note.
