Dedicated team vs extended team: Who owns the backlog?

Key takeaways

• Development team extension adds outside engineers to a team you already run: they work your backlog, in your sprints, under your engineering manager. A dedicated team is a separate group that owns a slice of the product, and the backlog and the lead for that slice can sit on either side of the contract.
• Every engagement has three things somebody has to own: the roadmap, the order of the backlog, and the lead who decides how the work gets built. Extension leaves all three with you. A dedicated team moves at least one of them across.
• Vendors use "dedicated team" for several different arrangements. Six vendor pages from five vendors, fetched for this guide, put the backlog and the lead in four different seats, so the label tells you less than the ownership questions do.
• Extension strains past about three external engineers on one team, when your manager turns into a dispatcher. A dedicated team strains when nobody on your side owns the order of its backlog.
• Before you sign, write one named person against each of the three, and check that the contract says the same thing.

Why this question matters

You have more backlog than engineers and two proposals on the desk. One offers to extend your team with three engineers. The other offers a dedicated team of five. The per-head rates are close. What differs is who decides what those people work on next Tuesday, and neither proposal spells it out. Choose without asking and you either bury your engineering manager in coordination, or find out in month two that the priorities you thought you owned are being reordered in a planning meeting you don't attend.

The frame: Three things someone has to own

Strip away the vendor vocabulary and every engagement has three seats.

The roadmap. What the product does next quarter, and why. This is product leadership's call, and none of the vendor pages reviewed for this guide claim it for the vendor.

The backlog order. Which piece of work is next, and what goes into this sprint. The 2020 Scrum Guide gives this to the product owner, says the product owner is one person, and says that when several teams work on one product they should share one product backlog and one product owner. Most teams don't run textbook Scrum, but the reason behind the rule holds everywhere: two people ordering overlapping work produce two plans.

The lead. Who decides how the work gets built, settles technical disputes and holds the review bar.

Extension and a dedicated team differ on which of these seats cross the contract line. With extension, none do. With a dedicated team, the roadmap stays with you, the lead usually moves, and the backlog is where the arrangements split. That split is the variable this guide follows. Where the lead sits, and what each lead model costs, is covered in depth in what a dedicated development team is, and who actually leads it. If what you want is to hand over a fixed scope at a fixed price, that's a different decision, set out in project scope vs. staff augmentation.

What is development team extension?

Development team extension, also sold as an extended development team or the extended team model, adds external engineers to a team you already run. They join your standups, pull tickets from your board, follow your review and release process, and report to your engineering manager. The vendor recruits, pays and replaces them. You own the roadmap, the backlog and the lead.

The vendor definitions agree on this one. Full Scale (September 2026) defines an extended team as one to three external engineers added to your in-house team and run by your engineering manager, with engineers pulling tickets from your existing sprint board. BairesDev describes the in-house team plus agency members who use the existing team's tools and processes. Edana says the external staff follow your rituals, tools and backlog.

Commercially it's the same engagement model as team augmentation, and some proposals call it software development team augmentation. The label table in FTE vs. contractor vs. team augmentation sorts out the names. What "extension" adds is a destination: the engineers go into one existing team as a group, and that team's lead absorbs them.

That's also its limit. Extension works when your team's process already works and the bottleneck is hands. It assumes a lead with room in their week, because every external engineer becomes one more person they plan for, unblock and review.

What is the dedicated team model, and who owns the backlog inside it?

In the dedicated team model, a vendor assembles a separate group that works only on your product and owns a slice of it end to end. No vendor claims your roadmap. Past that, the market doesn't agree: depending on whose page you read, the backlog and the lead sit with you, with a vendor manager, or with a lead inside the team.

Here's how five vendors describe the arrangement on their own pages, as of October 2026.

Read down the middle two columns. The same two words cover a team your own manager leads, a team whose sprint a vendor PM and Scrum Master run, a team that runs its own sprint while you act as product owner, and a team with a product owner supplied by the vendor.

Each of those arrangements works for somebody. They share a name, which is the problem with shopping by label.

The arrangement that deserves the hardest look is the vendor-side product owner. That person orders the backlog for your slice of the product, and their employer is the vendor. If your company already has a product owner for the product, you now have two people ordering work that overlaps, which is the exact situation the Scrum Guide's one-backlog rule exists to prevent. Sometimes it's the right trade, when you have no product owner to spare and the slice is cleanly separable. It should be a decision you made, with the cost of that seat visible on the invoice.

zoom_in

Dedicated team vs extended team: Who owns the backlog, the roadmap and the lead?

In an extended team you own all three and the outside engineers add capacity. In a dedicated team you keep the roadmap, the lead usually moves to the vendor's side or into the team, and the backlog goes wherever the contract puts it. The table compares extension with the two ways a dedicated team's backlog ends up owned.

The row that decides most engagements is the priority change, because that's the one you'll live through. Here's what it looks like in practice.

Week six, three ways

Take a hypothetical. You run a checkout product with an in-house team of six, and you've added outside engineers to rebuild the payment flow. In week six, a renewal for your largest customer turns on single sign-on that sales promised for next month. It has to jump the queue.

As an extended team. Three external engineers sit on your board. Your engineering manager moves the SSO tickets to the top that afternoon, pulls one external engineer and one employee onto it, and tells the team at the next standup. The payment rebuild slips a sprint, and everyone in the room knows why. The cost showed up earlier: for six weeks your manager has been planning, unblocking and reviewing for nine people instead of six, and the rebuild is where that time came from.

As a dedicated team with your product owner. Five engineers own the payment slice, led from inside by a senior engineer. Your product owner orders their backlog and sits in their planning. She brings the SSO request to the team's lead the same day. The lead says what it displaces and how long it takes, because the person estimating is the person who'll review the code. They re-plan the next sprint together. Your engineering manager hears about it in a summary.

As a dedicated team with a vendor product owner. Same five engineers, but the vendor supplies the product owner and a PM above the team. Your product owner sends the SSO request to the vendor PO. The vendor PO checks it against the slice's backlog, asks the team for an estimate, comes back two days later with a revised plan, and flags that it falls outside the current statement of work. None of that is bad faith. It's what a second backlog owner does: protect the plan they're accountable for. You get a clear answer and a change conversation, and the request has passed through three people before an engineer touches it.

Each version can be the right one. The extension is fastest to redirect and heaviest on your manager. The dedicated team with your product owner is fast to redirect, light on your manager, and needs a product owner with real hours. The vendor-owned backlog is lightest on everyone inside your company and slowest to turn. Decide which turning speed you need before the renewal arrives.

When should you extend your team, and when should you hand over a slice?

Extend when the work fits inside a team you already run and that team's lead has room. Hand over a slice when the work has a seam in the code, needs four or more engineers, and you can name a product owner for it. Five signals settle most cases.

1. How many external engineers land on one team. Full Scale's guidance is to restructure an extended team as a dedicated team once it passes three external engineers. Past that point, your manager is planning for a team that's often too big for one standup.
2. Your lead's week. If your engineering manager spends more time assigning and unblocking external engineers than making decisions, the extension has outgrown what it can hold.
3. A seam in the code. A dedicated team needs a boundary it can own: a service, a surface, a pipeline. If your codebase has no seam, a second team will spend its time negotiating with the first. Where an external team plugs into your engineering org covers how to find one, and who the external lead reports to.
4. A product owner with hours. A dedicated team without a product owner on your side ends up with a vendor-side one by default. If you can give the slice a product owner for real time each week, you keep the backlog.
5. How long the work runs. Full Scale argues six-week extensions don't pay back their onboarding. BairesDev positions dedicated teams for work of a year or more. Short, bounded work with a stable spec is usually a project-scope question.

Where A.Team sits: individual builders join your existing team self-managed, which is development team extension by another name, with a Team Success contact who runs kickoff and stays reachable. Team engagements arrive with the lead inside the team in a builder seat while your product owner keeps the roadmap and the backlog order, under one MSA with each builder on their own service order at one all-in rate, and there's no managing-partner fee on a standard engagement.

What goes wrong when nobody wrote the ownership down?

Most failures in either model trace to one of the three seats going unassigned. Three patterns recur.

The extension that turned into a team. It started as two engineers. Six months later there are five external engineers on one board, your engineering manager spends the week dispatching tickets, and the external engineers have started coordinating among themselves because nobody else has time. You have a dedicated team in all but name, with no lead. Name a lead for the external group and give them a slice, or bring the headcount back down.

Two backlogs. The vendor's product owner keeps the team's backlog in the vendor's tracker. Your product owner keeps the product backlog in yours. The two get reconciled in a weekly sync, and in between they drift. Keep one backlog in your tool, ordered by one person, with the team's slice as a filtered view of it.

The roadmap that left by default. Nobody from your side attends the dedicated team's planning, so the team's lead starts deciding what's next from the last brief they received. They're usually reasonable about it, which is why it goes unnoticed for a quarter. Put your product owner in planning every sprint, and make it a line in the statement of work.

The day-to-day version of these problems, in extended teams especially, is about access and ceremonies: external engineers who aren't in the architecture conversation can only execute instructions. Embedding contractors alongside FTEs covers that side.

What to do next

Before the next vendor call, write three names on a page: who owns the roadmap, who orders the backlog, and who leads the work. If all three are your people and the lead has room, you're buying development team extension; compare vendors on per-builder rates and how fast they replace someone. If you can name the roadmap owner and a product owner but not a lead with spare time, you want a dedicated team with the lead inside it. If you can't name a product owner for the slice, you're buying a vendor-side one, so ask to see that seat priced on its own. Then check that the statement of work names the same three people you did.

A.Team's team engagements put the lead inside the team and leave the backlog with your product owner, and the team is in your standups within 48 hours of sign-off.