Developers

Close

Developers on a Scrum Team

In Scrum, Developers are the people who create the product increment.

That word can be confusing. Scrum does not use Developers to mean only programmers. Developers include anyone on the Scrum Team who helps turn product backlog items into a usable increment: programmers, testers, analysts, designers, database specialists, UX researchers, writers, architects, or others needed to build the product.

A good Scrum Team does not treat those people as separate handoff stations. Developers work together to deliver a done increment each sprint.

Who This Page Is For

This page is for people who want to understand what Developers do in Scrum and how effective Scrum Teams work.

It is especially useful for:

  • People doing product work on Scrum Teams, including programmers, testers, analysts, designers, and specialists
  • Scrum Masters helping Developers move beyond handoffs and individual assignments
  • Product Owners who want better collaboration with the people building the product
  • Managers and leaders designing Scrum Teams
  • Scrum Teams trying to become more cross-functional, self-managing, or accountable for done work

What This Page Covers

This page explains who counts as a Developer in Scrum, what Developers are accountable for, how Scrum Teams should be structured, and what it means for Developers to work on a cross-functional, self-managing Scrum Team.

It also covers common problems that weaken Developer ownership, such as treating specialists as separate subteams, assigning work to individuals, splitting people across too many Scrum Teams, and calling work done before it meets the Definition of Done.

Who Are Developers in Scrum?

Developers are the people on the Scrum Team who create the product increment.

In software, that often includes programmers, testers, designers, analysts, database specialists, user experience people, architects, and others. On a non-software Scrum Team, the titles may be different. The test is simple: if someone is part of creating the increment, that person is one of the Developers.

This does not mean job titles disappear. Companies still have job titles. People still have specialties. Scrum simply gives the people doing the work a shared accountability: create a done increment that moves the product forward.

A tester does not stop being a tester. A designer does not stop being a designer. A database specialist does not stop having deep database expertise. But on a Scrum Team, those people are not separate departments passing work to one another. They are Developers working toward the same Sprint Goal.

Developers Are Not a Subteam

Scrum defines three accountabilities within the Scrum Team: Product Owner, Scrum Master, and Developers.

Developers are not a separate subteam inside the Scrum Team. The Product Owner, Scrum Master, and Developers work as one Scrum Team with different accountabilities.

This distinction matters because “the team” can become vague. Sometimes people use it to mean everyone on the Scrum Team. Other times they use it to mean only the people building the increment. To keep the language clear:

  • Use Scrum Team when referring to the Product Owner, Scrum Master, and Developers together.
  • Use Developers when referring to the people creating the increment.
  • Use Product Owner and Scrum Master when referring to those accountabilities specifically.

That language may feel more formal at first, but it prevents confusion.

What Developers Are Accountable For

Developers are accountable for creating a usable increment each sprint.

That includes more than writing code or completing assigned tasks. Developers are responsible for the work needed to turn selected product backlog items into something done.

Developers are accountable for:

  • Creating a plan for the sprint, the Sprint Backlog
  • Instilling quality by adhering to the Definition of Done
  • Adapting their plan each day toward the Sprint Goal
  • Holding one another accountable as professionals

In practice, that often means Developers:

  • Help refine product backlog items
  • Create and adapt the Sprint Backlog
  • Decide how to do the work
  • Collaborate to achieve the Sprint Goal
  • Ensure work meets the Definition of Done
  • Continuously improve how they work together

Scrum does not prescribe exactly how Developers estimate, design, test, code, document, or release. Those decisions depend on the product and the organization. But Scrum is clear that Developers own the work of creating the increment.

Developers Own the Sprint Plan

The Sprint Backlog is the Developers’ plan for the sprint.

The Product Owner explains what matters and why. The Product Owner helps Developers understand priorities, goals, users, customers, and tradeoffs. But the Developers decide how much work they believe they can complete and how they will organize the work.

That matters because the people doing the work know the work best.

Developers may break product backlog items into tasks. They may swarm on one item at a time. They may pair, split work by specialty, or use another approach. Scrum does not require one technique. It requires that Developers own the plan and adapt it as they learn.

The Sprint Backlog should not be treated as a contract handed to the Developers. It should be a useful plan they update during the sprint.

Cross-Functional Does Not Mean Everyone Does Everything

Scrum Teams should be cross-functional.

That does not mean every Developer can do every job equally well. Cross-functional means the Scrum Team as a whole has the skills needed to create a done increment.

Specialists are still valuable. In fact, most good Scrum Teams include specialists. A Scrum Team may need a strong tester, a designer, a data expert, a security specialist, or someone with deep domain knowledge.

The problem is not specialization. The problem is when specialization turns into a handoff process.

If analysts analyze, designers design, programmers code, testers test, and each group waits for the prior group to finish, the Scrum Team has recreated a phased process inside a sprint. Work moves slowly. Feedback comes late. Some people sit idle while others become overloaded.

Developers on a cross-functional Scrum Team try to reduce those handoffs. Specialists still use their strengths, but they also collaborate, overlap work, and help the Scrum Team finish valuable items.

Specialists Should Still Use Their Strengths

Cross-functional teamwork should not be used as an excuse to make everyone mediocre at everything.

People usually do their best work when they can use their strengths. A tester who loves testing should not be forced to spend every day doing work they dislike or do poorly. A designer should not be treated as interchangeable with a database engineer.

But specialists can still help outside their narrow specialty.

A tester may help clarify acceptance criteria before coding starts. A programmer may help create test data. A designer may work with another Developer while the interface is still flexible. A database specialist may pair with someone else so database knowledge does not become a bottleneck.

The goal is Developers who can finish work without unnecessary waiting while still using their individual strengths.

Developers Are Self-Managing

Developers decide how best to accomplish their work.

That is what Scrum means by self-management. It does not mean Developers choose whatever product they want to build. The Product Owner is still accountable for ordering the Product Backlog and maximizing value. Leaders still shape the environment, constraints, strategy, staffing, and goals.

Self-management means the people closest to the work have room to decide how to do that work.

This is important because product development work is complex. The best approach is often discovered while doing the work. Developers need enough freedom to adjust their plan, solve problems, and make tradeoffs as they learn.

Self-managing Developers are not unmanaged. They are trusted to manage their work within clear goals and boundaries.

The Best Scrum Teams Feel Like One Team

The best Scrum Teams have a strong sense that everyone is in it together.

When one Developer gets behind, others help. When a design decision is hard, Developers talk it through. When a test exposes a problem, the Scrum Team treats that as information, not as someone else’s fault. When the sprint is at risk, Developers adjust together and work with the Product Owner when scope needs to be clarified or renegotiated.

This is very different from the finger-pointing that happens on many traditionally managed projects:

  • “That was not in the specification.”
  • “I built what you asked for.”
  • “Testing is behind.”
  • “The database person is the bottleneck.”
  • “That is not my job.”

Those statements are signs that people may be working near one another, but not really as a Scrum Team.

Good Scrum Teams still disagree. In fact, healthy conflict is often a good sign. Developers trust one another enough to challenge ideas, improve designs, debate options, and make better decisions.

The difference is that the conflict is about the work, not about blame.

Recommended Scrum Team Size

A Scrum Team should be small enough to coordinate well and large enough to have the skills needed to create a done increment.

Many effective Scrum Teams have about five to nine people. The Scrum Guide allows ten or fewer people on the Scrum Team. The exact number matters less than whether the Scrum Team can communicate, collaborate, and finish meaningful work.

A Scrum Team that is too small may not have the skills it needs. A Scrum Team that is too large creates too many communication paths and tends to split into subgroups.

When a product needs more people, the answer is usually not to create one large Scrum Team. It is usually better to create multiple small Scrum Teams that can each deliver meaningful product increments.

Stable Scrum Teams Usually Outperform Temporary Groups

Scrum Teams take time to become good.

People need time to learn one another’s strengths, habits, preferences, skills, and working styles. They need time to develop trust. They need time to learn where they can rely on one another and where they need to improve.

That is why long-lived Scrum Teams are usually better than constantly reshuffled project groups.

When organizations move people from Scrum Team to Scrum Team too often, they keep paying the cost of forming new teams. People may stay busy, but the organization loses the performance that comes from Developers learning how to work well together.

A stable Scrum Team can still change when needed. But change the Scrum Team deliberately, not casually.

Avoid Splitting Developers Across Too Many Scrum Teams

A person who belongs to several Scrum Teams is rarely fully available to any of them.

Sometimes a specialist genuinely needs to support more than one Scrum Team. That may be unavoidable for a while. But it creates costs: more context switching, more scheduling problems, slower decisions, and less ownership.

As a general rule, Developers work better when they are dedicated to one Scrum Team.

If many people are split across multiple Scrum Teams, that may be a sign the organization is trying to run too many initiatives at once. The solution may not be asking people to multitask better. The solution may be doing less work in parallel.

How Developers Work During a Sprint

During a sprint, Developers turn selected product backlog items into a done increment.

They may start by discussing the goal, clarifying the work, identifying tasks, and deciding where to begin. As work progresses, Developers coordinate daily, inspect progress, and adjust the plan.

The best Developers avoid treating a product backlog item as a small waterfall project. They do not wait for analysis to finish, then design to finish, then coding to finish, then testing to begin. Instead, they overlap the work.

For example:

  • A tester helps clarify examples before coding begins.
  • A designer works with a programmer while the interface is still being shaped.
  • A programmer creates the first slice of functionality while another Developer starts tests.
  • Developers integrate and test continuously rather than waiting until the end.

This kind of collaboration helps Developers finish a few things instead of starting many things.

Developers and the Definition of Done

Developers are responsible for creating work that meets the Definition of Done.

That means a product backlog item is not done merely because one person finished a part. It is done when the item satisfies its acceptance criteria, meets the Scrum Team’s Definition of Done, and contributes to a usable increment.

A weak Definition of Done lets unfinished work hide. A strong one helps Developers see whether work is truly complete.

Developers should use the Definition of Done during planning, development, testing, review, and improvement. It should influence estimates. It should guide technical and testing decisions. It should help Developers avoid carrying almost-finished work from sprint to sprint.

How Leaders Help Developers Succeed

Leaders have a large influence on whether Developers can work effectively.

Developers cannot self-manage well if leaders constantly override decisions, move people on and off Scrum Teams, reward individual heroics over team outcomes, or assign more work than the Developers can realistically finish.

Leaders help Developers succeed by:

  • Creating stable Scrum Teams
  • Giving Scrum Teams clear goals
  • Staffing Scrum Teams with the skills needed to finish work
  • Reducing unnecessary multitasking
  • Encouraging collaboration across specialties
  • Rewarding team outcomes, not only individual output
  • Giving Developers authority over how they do their work
  • Helping remove organizational impediments

Developers need ownership, but they also need an environment where ownership is possible.

Scaling Scrum Teams

Scrum scales by adding Scrum Teams, not by making one Scrum Team huge.

When a product needs more people than one Scrum Team can support, create multiple small Scrum Teams that can each deliver useful increments. Those Scrum Teams will need to coordinate, especially when they work on the same product.

One common coordination approach is a Scrum of Scrums, where representatives from multiple Scrum Teams meet to discuss dependencies, integration risks, and cross-team impediments. It should help small Scrum Teams stay small while still coordinating across a larger product effort.

Scaling works best when Scrum Teams are organized around product value rather than narrow components. Component teams may be necessary in some cases, but they often increase dependencies and handoffs.

Common Problems with Developers on Scrum Teams

Developers Are Treated as Order Takers

Developers need to understand the goal behind the work.

If Developers receive only a list of tasks, the Scrum Team loses much of their judgment. Good Developers can often find simpler, safer, or more valuable ways to achieve a goal when they understand why the work matters.

Specialists Work in Separate Lanes

Specialists are valuable, but lane-based work creates handoffs.

If testers wait for programmers, programmers wait for designers, and everyone waits for someone else, the Scrum Team will struggle to finish a done increment inside a sprint.

Work Is Assigned to Individuals

Scrum works better when Developers own the Sprint Backlog together.

That does not mean every Developer works on every item. But it does mean Developers share responsibility for the sprint, rather than each person defending only assigned tasks.

Developers Start Too Much Work

Starting many items can make Developers look busy while little actually gets done.

Developers should pay attention to work in progress. It is usually better to finish a few important things than to start everything and end the sprint with a collection of almost-finished work.

The Scrum Team Is Not Stable

Scrum Teams that are constantly reshuffled have to keep relearning how to work together.

Some changes are necessary, but frequent reorganization makes it harder for Developers to build trust, improve their practices, and develop a reliable delivery rhythm.

The Scrum Team Lacks the Skills to Finish

A Scrum Team that depends on outside specialists for essential work is not fully cross-functional.

The answer may be to add a missing skill, help existing Developers broaden their skills, reduce the type of work the Scrum Team is asked to handle, or redesign Scrum Teams around product value.

Developers Do Not Have Real Authority

Calling Developers self-managing does not make them so.

If leaders assign all work, dictate the plan, move people around, or punish honest forecasts, Developers will stop acting like owners. They will wait to be told what to do.

A Quick Check for Developer Ownership

Use these questions to see whether Developers have the ownership Scrum expects:

  • Do Developers understand the Sprint Goal and the product outcome behind the work?
  • Do Developers decide how much work they can take into the sprint?
  • Do Developers create and update the Sprint Backlog?
  • Does the Scrum Team have the skills needed to create a done increment?
  • Are specialists collaborating, or are they handing work from one specialty to another?
  • Are Developers limiting work in progress so items can actually finish?
  • Does completed work meet the Definition of Done?
  • Are Developers dedicated enough to build real ownership of the work?
  • Do leaders give Developers room to decide how to do the work?
  • Do Developers improve how they work from sprint to sprint?

Use the answers to find the next conversation your Scrum Team needs to have.

FAQ

Why Does Scrum Call People Developers?

Scrum uses Developers to mean the people who create the product increment.

In software organizations, that includes programmers, but it can also include testers, designers, analysts, database specialists, UX researchers, writers, architects, and others. The term is broader than many job titles.

Are Testers and Designers Developers in Scrum?

Yes, if they are part of creating the increment.

A tester or designer does not lose that specialty. Scrum simply treats them as part of the group accountable for creating done product work each sprint.

Who Assigns Work to Developers in Scrum?

Developers organize their own work.

They may agree together that certain people will take certain tasks, but Scrum does not require a manager, Scrum Master, or Product Owner to assign work to individuals.

Who Decides How Much Work Goes Into a Sprint?

The Developers decide how much work they believe they can complete during the sprint.

The Product Owner explains priorities and desired outcomes. Sprint Planning should be collaborative, but the forecast of what can be done belongs to the Developers.

What Does Cross-Functional Mean in Scrum?

Cross-functional means the Scrum Team has the skills needed to create a done increment.

It does not mean every person can do every job. Specialists are fine. The Scrum Team should still be able to finish work without excessive dependence on outside groups.

Does Self-Managing Mean Developers Can Do Whatever They Want?

No.

Self-managing means Developers decide how to accomplish the work within the goals and boundaries of the product and organization. The Product Owner still orders the Product Backlog. Leaders still shape the environment and constraints.

How Big Should a Scrum Team Be?

A Scrum Team should be small enough to coordinate well and large enough to have the skills needed to create a done increment.

Many effective Scrum Teams have five to nine people. If a Scrum Team is too large, it will usually be better to split into multiple small Scrum Teams than to keep adding people.

Should Developers Be Dedicated to One Scrum Team?

Usually, yes.

Developers split across multiple Scrum Teams have more context switching, more scheduling conflicts, and less ownership. Some exceptions are unavoidable, but dedicated Scrum Team membership is usually healthier.

What If the Scrum Team Does Not Have Every Skill It Needs?

Treat that as a Scrum Team design problem.

The answer may be to add missing skills, help Developers broaden skills, reduce dependencies, or redesign Scrum Teams so each Scrum Team can deliver meaningful increments of value.