Scrum Developers: Team Size, Self-Managing Practices & Roles Guide (2026)

Developers are the people in a Scrum Team committed to creating any aspect of a usable Increment every Sprint. The role is not limited to software engineers - it includes anyone whose skills contribute directly to the product, such as testers, designers, UX researchers, database specialists, technical writers, and operations engineers.

Many practitioners still search for "Development Team" because that was the term's name until late 2020. The Scrum Guide 2020 update (opens in a new tab) retired "Development Team" in favor of "Developers" and folded it, along with the Product Owner and Scrum Master, into a single, unified Scrum Team of accountabilities rather than three separate sub-teams. This guide uses the current "Developers" terminology throughout, but explains the rename in detail because the older language is still common in job postings, certification study guides, and everyday conversation.

This is a comprehensive resource for anyone who needs to understand what Developers are accountable for, how large a Developers group should be, the difference between self-organizing and self-managing, what cross-functionality really requires, and the mistakes that quietly undermine even well-intentioned teams.

Quick Answer: Scrum Developers at a Glance

Aspect	Details
Official term (Scrum Guide 2020)	"Developers" - the 2017 Guide's "Development Team" label was retired
Team size	Scrum Team is 10 or fewer people total; Developers typically number 3-9
Structure	Cross-functional (all skills needed to create an Increment) and self-managing (decide who does what, when, and how)
Core accountabilities	Creating the Sprint Backlog plan, instilling quality via the Definition of Done, adapting the plan daily toward the Sprint Goal, holding each other accountable
Internal hierarchy	None - no sub-teams, no titles, no one Developer directing another's work
Key 2020 distinction	Self-managing (who, what, and how) replaced self-organizing (how only) as the term describing the whole Scrum Team

What Are Developers in Scrum?

Developers are one of three accountabilities that make up the Scrum Team, alongside the Product Owner and Scrum Master. They are the people who turn a Product Backlog item into a working, valuable piece of the product.

Despite the name, "Developers" is not limited to software engineers. The Scrum Guide is explicit that Developers can include:

• Software engineers and programmers
• Quality assurance and test engineers
• UX/UI designers and researchers
• Database administrators and data engineers
• Technical writers and documentation specialists
• DevOps, infrastructure, and platform engineers
• Any other specialist whose skill is genuinely needed to create the Increment

From Development Team to Developers: Why the Term Changed

The 2017 Scrum Guide (opens in a new tab) described a Scrum Team made up of three parts: a Product Owner, a Scrum Master, and a "Development Team." That phrasing implied a structure where the Development Team was a distinct sub-team that received work from the Product Owner - functionally similar to how a project manager might hand requirements to an engineering team in a traditional structure.

The 2020 Scrum Guide removed "Development Team" entirely. In its place, the guide defines one Scrum Team containing three accountabilities: Developers, Product Owner, and Scrum Master. This was a deliberate correction of a common misreading, not a simple word swap. Ken Schwaber and Jeff Sutherland wanted to eliminate the perception that the Product Owner and Scrum Master stand outside or above the people doing the work.

What actually changed:

• "Development Team" (a sub-team within the Scrum Team) became "Developers" (one of three accountabilities within a single Scrum Team)
• The idea of a Product Owner or Scrum Master "managing" a separate Development Team was explicitly ruled out
• "Self-organizing" (how work gets done) was replaced by "self-managing" (who does what, when, and how) - covered in detail in the next section
• The team's accountabilities were rewritten as a short, explicit list rather than a loose description of "responsibilities"

Why the older term persists: Certification study guides published before 2021, job postings written by recruiters unfamiliar with the update, and countless blog posts and books still use "Development Team." Search volume for "development team" in a Scrum context remains high for exactly this reason - this guide treats the terms as synonymous historically, while defaulting to "Developers" as the current, correct usage.

Developers' Accountabilities per the Scrum Guide 2020

The Scrum Guide lists four things Developers are always accountable for. These are not optional practices to adopt when convenient - they define the accountability itself.

Accountability	What It Means in Practice
Creating the Sprint Backlog plan	Developers select Product Backlog items during Sprint Planning and build the Sprint Backlog themselves
Instilling quality via the Definition of Done	Every increment of work must satisfy the team's Definition of Done before it counts as finished
Adapting the plan daily toward the Sprint Goal	The Daily Scrum is where Developers inspect progress and re-plan the next 24 hours
Holding each other accountable as professionals	No external manager enforces standards - Developers hold themselves and each other to the commitments they made

Creating the Sprint Backlog Plan

During Sprint Planning, Developers - not the Product Owner and not the Scrum Master - decide how much Product Backlog work they can realistically commit to and how they will build it. The resulting Sprint Backlog is a living plan, not a fixed contract; Developers update it throughout the Sprint as they learn more.

In practice, this means:

• Developers forecast their own capacity rather than accepting an externally imposed commitment
• The Sprint Backlog is owned and edited by Developers, visible to the whole Scrum Team
• Task breakdown, technical approach, and sequencing decisions belong to Developers alone

Instilling Quality via the Definition of Done

The Definition of Done is the objective, shared standard that separates "code that compiles" from "an Increment that is genuinely usable." Developers do not just meet the Definition of Done - they are the ones who craft and evolve it, since they are closest to the technical practices required to satisfy it.

Adapting the Plan Daily Toward the Sprint Goal

Every day, Developers use the Daily Scrum to inspect progress against the Sprint Goal and adjust the Sprint Backlog accordingly. This is where self-management shows up most visibly: no one outside the team assigns the next day's work.

A healthy adaptation pattern looks like:

1. Compare actual progress to the Sprint Goal, not to a task checklist
2. Identify anything blocking progress and decide, as a team, how to resolve it
3. Re-sequence remaining Sprint Backlog work based on what was learned
4. Flag to the Product Owner immediately if the Sprint Goal itself is at risk

Holding Each Other Accountable

There is no manager inside the Scrum Team assigning consequences for missed commitments. Developers hold each other accountable through direct, professional conversation - reinforced by the Sprint Retrospective, where the team explicitly inspects how well it lived up to its own working agreements.

Self-Managing vs. Self-Organizing: Understanding the Nuance

This distinction is one of the most frequently misunderstood changes in the 2020 Scrum Guide, and it is worth explaining precisely because so much existing material (and even some certification prep) still conflates the two terms.

Concept	Scope of Decision	Scrum Guide Version
Self-organizing	The team decides how to accomplish its work	Central term in the 2017 Guide
Self-managing	The team decides who does the work, when, and how	Replaced self-organizing as the defining term in the 2020 Guide

The 2017 Guide's self-organizing principle addressed how work got done, implicitly leaving who does what and sometimes even what to build subject to outside direction. The 2020 Guide's self-managing principle is broader: it explicitly hands Developers control over who picks up which piece of work and when it happens, not just the technical how.

Concretely, self-managing means:

• No manager or Scrum Master assigns tasks to individual Developers
• Developers themselves decide who works on what, based on skills, capacity, and interest
• The team decides internally when during the Sprint each piece of work happens
• Technical approach and implementation details remain entirely the team's call

Cross-Functionality and T-Shaped Skills

Cross-functionality means the Developers group, taken together, has every skill needed to turn a Product Backlog item into a usable Increment - without depending on people outside the team. It does not mean every individual Developer can do everything.

T-shaped skills describe the ideal individual profile inside a cross-functional team:

• The vertical bar of the "T" represents deep expertise in one discipline (e.g., backend engineering, UX research, database performance)
• The horizontal bar represents working competence across adjacent disciplines (e.g., a backend engineer who can write basic front-end code, run a manual test pass, or review a design mockup)

Why T-shaped skills matter more than pure specialists:

• Reduces single points of failure - if one specialist is out, work does not fully stop
• Shrinks hand-off delays between disciplines within a single Sprint
• Increases flexibility when the Sprint Backlog's mix of work shifts mid-Sprint

Building cross-functionality without diluting expertise:

1. Pair specialists with generalists intentionally, not just when convenient
2. Rotate ownership of recurring task types (code review, deployment, support triage) across the team
3. Budget explicit time for cross-training, not just feature delivery
4. Track "bus factor" per skill area - if only one person can do something critical, treat it as a risk to resolve

Team Size and Composition

The Scrum Guide recommends a total Scrum Team size of 10 or fewer people, which typically translates to 3 to 9 Developers once the Product Owner and Scrum Master are counted separately (in Scrum, they are also part of the 10, though the Scrum Master and Product Owner can sometimes also perform Developer work if they have the skills and capacity).

Team size	Characteristics	Recommendation
1-2 Developers	Minimal redundancy, high individual dependency risk	Generally too small - avoid if possible
3-5 Developers	Lean, fast communication, works well for focused products	Solid for early-stage products or narrow scopes
6-9 Developers	Enough capacity for meaningful throughput while communication stays manageable	Sweet spot for most established product teams
10+ Developers	Communication overhead grows faster than output; coordination becomes a full-time concern	Split into multiple Scrum Teams instead

Composition guidance beyond headcount:

• Prioritize covering the skills the product actually needs over hitting a specific number
• A narrow product (e.g., a single mobile app) needs a different skill mix than a broad platform
• Include testing and design skills inside the team rather than treating them as external services
• Avoid building a team entirely of specialists in one discipline - that recreates functional silos inside a single Sprint

Establishing Team Working Agreements

Working agreements are the explicit, team-authored rules that make self-management and peer accountability practical day to day. Without them, "hold each other accountable" has no shared standard to hold anyone to.

Common categories of working agreements:

Category	Example Agreement
Availability	Core collaboration hours when everyone is reachable, even across time zones
Code review	No merge without at least one approving review; reviews turned around within 24 hours
Communication	Daily Scrum starts on time regardless of who is present; blockers get raised the same day
Definition of Done	Explicit, written, and revisited at least once per quarter
Conflict handling	Disagreements are raised directly with the person first, not escalated immediately
Meeting discipline	Cameras on for remote sync meetings; agenda shared in advance

How to create working agreements that stick:

1. Draft them collaboratively in a workshop, never impose them top-down
2. Keep the initial list short - five or six agreements the team will actually follow beats fifteen that get ignored
3. Post them somewhere visible (team wiki, board header) so they are a living reference, not a forgotten document
4. Revisit and revise them explicitly during a Sprint Retrospective every few Sprints

Technical Practices That Support High-Performing Developers

Self-management and quality accountability only work if Developers have the technical foundation to move fast without breaking the Definition of Done. The following practices are what typically separates a Developers group that can adapt daily from one that dreads every release.

• Continuous Integration and Continuous Delivery (CI/CD): Automated build, test, and deployment pipelines that make "adapting the plan each day" safe rather than risky. See Continuous Integration for implementation guidance.
• Automated testing: Unit, integration, and end-to-end test suites that let the team verify the Definition of Done quickly and repeatedly rather than relying on slow manual regression passes. See Agile Testing.
• Pair and mob programming: Two or more Developers working on the same piece of code simultaneously, spreading knowledge and catching defects earlier than a solo-then-review workflow.
• Code review: A standing practice, not an afterthought - review criteria should be part of the Definition of Done, not a separate, optional gate.
• Trunk-based development or short-lived branches: Reduces merge conflict risk and keeps the Increment closer to release-ready throughout the Sprint, not just at the end.
• Refactoring as ongoing work: Small, continuous code-quality improvements folded into regular Sprint Backlog items rather than deferred to a rare "tech debt Sprint."

Industry-Specific Examples for Developers

How Developers apply the Definition of Done, technical practices, and quality bar shifts meaningfully by industry. These checklists show standing practices worth adding for common contexts.

SaaS / Cloud Product Teams

✓ Code reviewed by at least one peer before merge ✓ Automated unit and integration tests passing (target >75% coverage) ✓ CI/CD pipeline runs green before deployment ✓ Feature flags used for risky or incomplete functionality ✓ Uptime and monitoring alerts configured for new services ✓ Deployed to staging and smoke-tested before production release

Healthcare Software Teams

✓ Dual code review required for any code touching Protected Health Information (PHI) ✓ HIPAA compliance checklist completed and signed off ✓ Audit logging implemented for all PHI access and modification ✓ Encryption verified for PHI at rest and in transit ✓ Role-based access control tested, including negative test cases ✓ Security vulnerability scan passed with no high or critical findings

Financial Services Teams

✓ PCI-DSS and SOC 2 control requirements verified for new code ✓ Encryption implemented for all financial data flows ✓ Fraud-detection logic tested against known false-positive/false-negative patterns ✓ Regulatory documentation updated alongside the code change ✓ Independent security review completed for payment-adjacent functionality ✓ Rollback procedure tested and documented before release

E-commerce Teams

✓ Payment processing paths tested against failure and retry scenarios ✓ Page load and checkout performance benchmarks met ✓ Cart and inventory logic tested under concurrent-user conditions ✓ Peak-load readiness verified ahead of seasonal traffic events ✓ Accessibility of checkout flow validated ✓ Analytics and conversion tracking confirmed working post-deployment

Mobile App Teams

✓ Tested on real devices across supported OS versions, not simulators only ✓ Battery and performance impact assessed for new features ✓ Offline behavior and poor-connectivity handling verified ✓ App store guideline compliance checked before submission ✓ iOS/Android parity confirmed where features should behave identically ✓ Crash reporting and analytics instrumented for the new release

Enterprise / DevOps Teams

✓ Infrastructure-as-code changes reviewed alongside application code ✓ Security scanning integrated into the CI/CD pipeline, not run manually after the fact ✓ Rollback and disaster-recovery procedures tested, not just documented ✓ Configuration drift checked against the intended infrastructure state ✓ Cross-team dependencies communicated before merge, not after ✓ Monitoring and alerting updated to cover new infrastructure components

Government / Public Sector Teams

✓ Section 508 / WCAG 2.1 AA accessibility validated for all UI changes ✓ FISMA or equivalent security control requirements checked ✓ Public records and data retention obligations reviewed for new data flows ✓ Procurement and compliance constraints accounted for in the Definition of Done ✓ Plain-language content review completed for citizen-facing features ✓ Change documented sufficiently for public transparency requirements

EdTech Teams

✓ FERPA and COPPA compliance verified for any student-data-touching feature ✓ Accessibility tested for the Sprint's UI changes, including screen-reader support ✓ Student data anonymized or minimized wherever technically feasible ✓ Pedagogical impact considered, not just technical correctness ✓ Parental or institutional consent flows tested where applicable ✓ Data privacy safeguards built into the Definition of Done, not added after launch

Developers Maturity Model

Developers' capability to self-manage, stay cross-functional, and sustain quality grows progressively. Use this model to set realistic expectations for where a team sits and what to invest in next.

Stage 1: Basic / Forming (Sprints 1-6)

Timeline: the first 6 Sprints of a newly formed Developers group

Characteristics:

• Heavy reliance on manual testing and ad hoc code review
• Definition of Done exists but is minimal, and sometimes skipped under pressure
• Task assignment still shows traces of external direction (a lead "handing out" work)
• Cross-functionality is limited - most work routes to whichever specialist "owns" that area

Focus for this stage:

• Write down an initial Definition of Done, even a short one, and hold to it without exception
• Establish basic working agreements (see above)
• Start pairing specialists with generalists on a subset of tasks each Sprint
• Practice self-selecting work during Sprint Planning rather than having it assigned

Stage 2: Intermediate (Sprints 7-15)

Timeline: Sprints 7 through roughly 15

Characteristics:

• Automated test coverage growing (typically 50-70%)
• A working CI/CD pipeline exists, even if not fully automated end to end
• Code review is consistent and uses a shared checklist
• The team has a written, revisited Definition of Done

Focus for this stage:

• Increase automated test coverage and reduce reliance on manual regression passes
• Rotate ownership of recurring tasks (deployment, on-call, review) across more of the team
• Begin tracking "bus factor" for critical skills and actively reduce single points of failure
• Use the Sprint Retrospective explicitly to revise working agreements, not just discuss morale

Stage 3: Advanced / High-Performing (Sprints 16-30)

Timeline: Sprints 16 through roughly 30

Characteristics:

• Comprehensive test automation (typically >80% coverage) including integration and end-to-end suites
• Fully automated CI/CD with staged, low-risk deployments
• Genuine cross-functionality - most Sprint Backlog items can be picked up by more than one Developer
• The team resolves most technical and interpersonal issues without outside intervention

Focus for this stage:

• Add performance, security, and accessibility testing to the standard Definition of Done
• Mentor newer Developers or newer teams within the organization
• Actively manage technical debt as visible, prioritized backlog items rather than deferred work
• Take on more ambiguous problems that require judgment, not just execution

Stage 4: Expert (Sprint 31+)

Timeline: Sprint 31 onward

Characteristics:

• The team routinely improves its own engineering practices without prompting
• Technical practices and working agreements are treated as living, versioned artifacts
• The Developers group contributes reusable tools, patterns, or playbooks to other teams
• Peer accountability is fully internalized - conflicts and quality lapses are addressed directly and early

Focus for this stage:

• Contribute engineering practices and Definition of Done templates to the wider organization
• Take an active role in onboarding and mentoring across multiple teams
• Periodically revisit fundamentals - even expert teams benefit from re-examining working agreements
• Support scaling decisions (see Advanced Strategies) as the organization grows

Common Developers Mistakes

Mistake 1: Assigning Sprint Backlog Items to Individuals From Outside the Team

Problem: A manager, team lead, or even the Product Owner assigns specific tasks to specific Developers during or before Sprint Planning.

Why It's Problematic: This directly violates self-management - Developers, not an outside role, decide who does what and when.

Fix: Let Developers self-select work during Sprint Planning based on skill, capacity, and interest.

Prevention: Make self-selection an explicit, stated working agreement, and have the Scrum Master intervene if outside assignment recurs.

Mistake 2: Confusing Self-Managing With No Accountability

Problem: A team interprets "no one directs us" as "no one can question our decisions," and quality or commitments slip without pushback.

Why It's Problematic: Self-managing replaces external management with internal accountability - it does not remove accountability altogether.

Fix: Reinforce peer accountability explicitly in the Sprint Retrospective; make missed commitments a standing discussion topic, not a taboo one.

Prevention: Build working agreements that name what happens when a commitment is missed, agreed to by the team itself.

Mistake 3: Building Silos Despite Being "Cross-Functional" on Paper

Problem: Only one person can safely touch a given component, even though the team nominally has all the needed skills.

Why It's Problematic: A single point of failure defeats the purpose of cross-functionality - the team is only cross-functional in name.

Fix: Deliberately pair the sole owner of a skill area with someone else on relevant tasks until the bus factor improves.

Prevention: Track bus factor per critical skill area as a standing item in planning or retrospectives.

Mistake 4: Bending the Definition of Done Under Deadline Pressure

Problem: The team skips agreed-upon quality steps (testing, review, documentation) to hit a release date.

Why It's Problematic: Quality debt incurred this way rarely gets paid back - it accumulates and slows every future Sprint.

Fix: Treat the Definition of Done as non-negotiable; if the Sprint Backlog cannot be completed within it, reduce scope instead of quality.

Prevention: Make the Definition of Done visible and explicitly review adherence during Sprint Review and Retrospective.

Mistake 5: Growing the Team Past Nine Developers Instead of Splitting

Problem: A Developers group balloons to 12-15 people to add capacity, rather than forming a second Scrum Team.

Why It's Problematic: Coordination overhead grows faster than output once a team exceeds roughly nine people, and Scrum events start to strain against their timeboxes.

Fix: Split into two Scrum Teams sharing a Product Backlog, coordinated through practices like scaling Scrum.

Prevention: Treat nine Developers as a soft ceiling and plan the split before the team feels the pain of size.

Mistake 6: Letting Titles and Informal Hierarchy Creep Back In

Problem: A "senior" or "lead" Developer starts directing others' day-to-day tasks like an informal manager.

Why It's Problematic: The Scrum Guide is explicit that there is no hierarchy within Developers - reintroducing one undermines self-management and peer accountability alike.

Fix: Redirect technical leadership toward mentoring and influence, not task assignment or approval authority.

Prevention: Make "no internal hierarchy" an explicit onboarding topic for new Developers and new leads alike.

Mistake 7: Treating Testing and Design as External Services

Problem: Testers or designers sit outside the Developers group and receive work as hand-offs rather than participating in the Sprint itself.

Why It's Problematic: This recreates a mini-waterfall inside every Sprint and breaks the "usable Increment each Sprint" commitment.

Fix: Bring testing and design skills fully inside the Developers group, involved from Sprint Planning onward.

Prevention: When forming or restaffing a team, prioritize the skills the product needs over convenient organizational reporting lines.

Mistake 8: Skipping Technical Practices to "Move Faster"

Problem: The team skips automated testing, CI/CD, or code review to hit short-term deadlines.

Why It's Problematic: This trades a small, visible short-term speed gain for a much larger, hidden long-term cost in defects and slower future delivery.

Fix: Invest in technical practices as part of the Definition of Done, not as optional extras.

Prevention: Track defect escape rate and deployment frequency over time to make the cost of skipped practices visible.

Mistake 9: No Working Agreements, or Agreements No One Follows

Problem: The team has no explicit norms, or has norms that were written once and never referenced again.

Why It's Problematic: Without shared, followed norms, peer accountability has nothing concrete to hold anyone to.

Fix: Draft a short, specific set of working agreements collaboratively and revisit them regularly (see above).

Prevention: Make working agreement review a standing Sprint Retrospective agenda item every few Sprints.

Mistake 10: Understaffing the Team to Save Cost

Problem: A team of one or two Developers is expected to cover the full range of skills needed for the product.

Why It's Problematic: Minimal redundancy means any absence, illness, or departure creates an immediate delivery risk, and true cross-functionality becomes impossible.

Fix: Staff toward the Scrum Guide's recommended range, prioritizing the specific skills the product genuinely needs.

Prevention: Treat "3 Developers minimum" as a starting point for viability, not an aspirational target to grow into eventually.

How to Build and Grow a Strong Developers Group

Building a strong Developers group is a deliberate, staged process rather than something that happens automatically once people are assigned to a team.

Step 1: Staff for the skills the product needs (Weeks 1-2)

• Map the skills required to deliver a usable Increment for this specific product
• Prioritize covering gaps over hitting a specific headcount
• Aim for 3-9 Developers based on product scope, not organizational convenience

Step 2: Establish foundational agreements (Sprints 1-3)

• Draft an initial Definition of Done collaboratively
• Create basic working agreements covering availability, communication, and code review
• Clarify explicitly that task assignment happens inside the team, not from outside it

Step 3: Build technical foundations (Sprints 1-10)

• Stand up CI/CD, even in a minimal form, as early as possible
• Introduce automated testing incrementally rather than all at once
• Establish a consistent code review practice with a shared checklist

Step 4: Grow cross-functionality deliberately (Sprints 5-20)

• Pair specialists with generalists on a rotating basis
• Track bus factor per skill area and address concentration risk directly
• Rotate ownership of recurring operational tasks (deployment, on-call, review)

Step 5: Mature accountability and self-management (ongoing)

• Use the Sprint Retrospective to review and refine working agreements
• Coach the team toward resolving conflicts and quality lapses directly, without escalation
• Gradually reduce the Scrum Master's involvement in day-to-day facilitation as the team matures

Measuring Developers Team Effectiveness

A Developers group's health is partly intangible (trust, collaboration quality), but several concrete signals reveal whether self-management and cross-functionality are actually working in practice, not just declared in a team charter.

Metric	What It Indicates
Definition of Done adherence rate	How often "Done" work genuinely meets every agreed criterion versus quietly skipping steps under pressure
Bus factor per skill area	How many Developers could cover a critical skill if one person were unavailable - a direct read on real cross-functionality
Cycle time and velocity stability	Whether Sprint-to-Sprint swings shrink as working agreements and technical practices mature
Defect escape rate	Whether quality practices (testing, review, Definition of Done) are catching issues before release
Deployment frequency	How often the team safely ships, a proxy for how well CI/CD and automated testing support daily adaptation
Working agreement adherence	Whether the team's own stated norms are actually followed, checked periodically during the Sprint Retrospective
Task self-selection rate	How often Developers pick up work themselves during Sprint Planning versus having it assigned by someone outside the team

Track these metrics over several Sprints rather than reacting to any single data point - a team refining its Definition of Done, for instance, often shows a temporary dip in throughput before cycle time stabilizes at a faster, more sustainable pace.

Advanced Strategies and Scaling Considerations

As products and organizations grow, a single Developers group eventually cannot cover the necessary scope alone. Several strategies extend Scrum's structure without abandoning its core accountabilities.

When one team is not enough:

• Split into multiple Scrum Teams sharing one Product Backlog and one Product Owner (or a Product Owner team) once a single Developers group would otherwise exceed roughly nine people
• Coordinate shared dependencies through a Scrum of Scrums, where representative Developers from each team surface cross-team blockers
• Keep each individual Developers group's internal self-management intact - scaling frameworks coordinate between teams, they should not re-centralize decisions within a team

Framework-level options for multiple teams:

• Nexus: A lightweight framework built directly on Scrum, adding a Nexus Integration Team accountable for identifying and resolving cross-team dependencies and ensuring a single, integrated Increment across roughly 3-9 Scrum Teams.
• LeSS (Large-Scale Scrum): Extends Scrum's structure to multiple teams sharing one Product Backlog, one Sprint, and one Definition of Done, deliberately minimizing additional roles or ceremonies beyond what single-team Scrum already has.
• Scrum of Scrums: The simplest scaling mechanism - representatives from each team meet regularly to coordinate dependencies, without introducing a new framework layer.

Practical scaling guidance:

• Prioritize keeping the Definition of Done consistent across teams working on the same product
• Address team dynamics issues at the team level before they compound across multiple teams
• For distributed or globally spread Developers groups, review dedicated guidance on distributed teams
• Resist adding coordination overhead (extra meetings, extra reporting layers) faster than it is actually needed - scale the minimum necessary structure, not the maximum available one

Conclusion

Developers are the accountability inside the Scrum Team responsible for turning a Product Backlog into a genuinely usable Increment, every Sprint, without external direction on who does what or how. The 2020 rename from "Development Team" to "Developers" was a deliberate correction: there is one Scrum Team, not a Product Owner and Scrum Master standing above a separate delivery team.

Your next three actions:

1. Check whether your Developers group's size sits in the 3-9 range - if it has grown past nine, plan a split rather than absorbing the coordination cost
2. Audit whether task assignment genuinely happens inside the team, or whether an outside role is quietly still assigning work
3. Revisit your Definition of Done at the next Sprint Retrospective and confirm the team actually adheres to it under deadline pressure, not just on paper

Cross-functionality, self-management, and peer accountability are not achieved once and then maintained automatically - they are built the same way the product is: iteratively, Sprint over Sprint, through honest inspection and deliberate adaptation.

Frequently Asked Questions (FAQs) / People Also Ask (PAA)