Entwicklungsteam im Scrum

Entwicklungsteam im Scrum: Definition – Ein Scrum-Projekt steht und fällt mit der Leistungsfähigkeit des Teams, das die eigentliche Wertschöpfung erbringt. Gleichzeitig herrscht viel Unsicherheit: Was genau ist ein Entwicklungsteam im Scrum, wie unterscheidet es sich von „Developers“ im aktuellen Scrum Guide, und wie stellt man ein solches Team in der Praxis wirksam auf?
Dieser Beitrag gibt eine klare, praxisnahe Einordnung für Entscheider, Projektleiter und Fachverantwortliche – von der Definition über Aufgaben und Zusammensetzung bis zu typischen Stolperfallen und konkreten Handlungsempfehlungen für Ihren Alltag.

Entwicklungsteam im Scrum
Entwicklungsteam im Scrum

Was ist ein Entwicklungsteam im Scrum?

Ein Entwicklungsteam im Scrum ist die Gruppe von Fachleuten, die am Ende jedes Sprints ein fertiges, nutzbares Produktinkrement liefert. Es organisiert sich selbst, ist interdisziplinär besetzt und trägt gemeinsam die Verantwortung für Qualität und Ergebnis.

Kurz gefasst:

Wichtig: Im Scrum Guide 2020 wurde der Begriff „Entwicklungsteam“ offiziell durch „Developers“ innerhalb des Scrum Teams ersetzt.[1][2] Der zugrunde liegende Inhalt ist aber weitgehend gleich geblieben. In diesem Artikel werden beide Begriffe entsprechend kontextbezogen verwendet.


Historischer Kontext: Vom „Entwicklungsteam“ zu „Developers“ im Scrum Team

Bis zur Überarbeitung des Scrum Guides 2020 war das Scrum Team in drei Rollen gegliedert:

Das Entwicklungsteam war das „Team im Team“, das für die Umsetzung verantwortlich war. Dieses Modell führte jedoch in der Praxis häufig zu Abgrenzungsproblemen („die da im Entwicklungsteam vs. der Rest“).

Mit dem Scrum Guide 2020 wurde das Modell vereinfacht:

Der Begriff „Entwicklungsteam“ bleibt im deutschsprachigen Raum trotzdem weit verbreitet – gerade in Stellenanzeigen, Projektbeschreibungen oder Schulungsunterlagen. Wenn in Ihrem Unternehmen also noch von einem „Entwicklungsteam im Scrum“ gesprochen wird, ist fachlich das Developer-Team innerhalb des Scrum Teams gemeint.


Aufgaben und Verantwortlichkeiten des Entwicklungsteams

Das Entwicklungsteam (bzw. die Developers im Scrum Team) ist für die operative Wertschöpfung verantwortlich. Typische Aufgaben sind:

Entscheidend ist:

Das Entwicklungsteam trägt gemeinsam Verantwortung für das Ergebnis.
Es gibt im Scrum keine interne Hierarchie innerhalb der Developers (z. B. keinen „Lead Developer“, der fachliche Anweisungen verteilt – auch wenn es natürlich Seniorität und Erfahrung gibt).


Zusammensetzung: Wer gehört zum Entwicklungsteam?

Ein verbreiteter Irrtum ist, dass ein Entwicklungsteam nur aus Softwareentwicklern besteht. Im Scrum-Sinne gilt:

Jeder, der direkt an der Erstellung des Produktinkrements arbeitet, ist Teil des Entwicklungsteams (Developers).

Typische Profile sind z. B.:

Nicht zum Entwicklungsteam zählen typischerweise:


Optimale Größe des Entwicklungsteams

Scrum empfiehlt für das gesamte Scrum Team (inkl. Product Owner und Scrum Master) eine Größe von 3 bis 10 Personen. Daraus ergibt sich für das Entwicklungsteam typischerweise eine Größe von:

Zu kleine Teams:

Zu große Teams:

In der Praxis bewährt sich ein kleines, stabil besetztes Kernteam, das bei Bedarf punktuell durch externe Spezialisten unterstützt wird – aber die Verantwortung im Team belässt.


Interdisziplinarität und T-Shaped Skills

Ein zentrales Erfolgskriterium für ein Entwicklungsteam im Scrum ist seine Interdisziplinarität:

Dazu kommt das Konzept der T-Shaped Skills:

Vorteile T-förmiger Fähigkeiten:

Für Führungskräfte heißt das: nicht nur Spezialisten rekrutieren, sondern Lernbereitschaft und Kooperationsfähigkeit aktiv fördern.


Zusammenarbeit mit Product Owner und Scrum Master

Für Entscheider ist die klare Abgrenzung zwischen den Verantwortlichkeiten wichtig:

Product Owner

Scrum Master

Entwicklungsteam / Developers

Wichtige Leitlinie:
Product Owner bestimmen nicht, wie das Team arbeitet, und Management schreibt nicht vor, wie viel geliefert wird. Das sind Kernkompetenzen des Entwicklungsteams.


Arbeitsweise im Sprint: So arbeitet ein Entwicklungsteam in der Praxis

Ein typischer Sprint-Ablauf aus Sicht des Entwicklungsteams:

  1. Product Backlog Refinement (kontinuierlich)
    • Anforderungen gemeinsam mit dem Product Owner verfeinern
    • Akzeptanzkriterien klären
    • Grobe Schätzungen (z. B. Story Points) vornehmen
  2. Sprint Planning
    • Product Owner stellt das gewünschte Ziel und priorisierte Backlog-Items vor
    • Entwicklungsteam schätzt, was realistisch in einem Sprint umgesetzt werden kann
    • Identifikation eines klaren Sprintziels
    • Planung der technischen Umsetzung („Wie erreichen wir das Ziel?“)
  3. Daily Scrum
    • Max. 15 Minuten pro Tag
    • Entwicklungsteam synchronisiert sich über Fortschritt, Hindernisse und nächsten Schritt
    • Fokus auf Plan für die nächsten 24 Stunden, nicht auf Statusberichte für das Management
  4. Umsetzung und Qualitätssicherung
    • Inkrementelle Entwicklung
    • Automatisierte Tests, Code-Reviews, Pair-Programming, DevOps-Praktiken
    • Kontinuierliche Abstimmung mit dem Product Owner bei Unklarheiten
  5. Sprint Review
    • Entwicklungsteam demonstriert das fertige Inkrement
    • Product Owner und Stakeholder geben Feedback
    • Gemeinsame Anpassung des Product Backlogs
  6. Sprint Retrospektive
    • Entwicklungsteam, Product Owner und Scrum Master reflektieren Zusammenarbeit, Prozesse, Tools
    • Identifikation konkreter Verbesserungsmaßnahmen für den nächsten Sprint

Dieses schlanke, aber konsequent eingehaltene Event-Set ist entscheidend, damit das Entwicklungsteam dauerhaft lieferfähig bleibt.


Typische Missverständnisse und Anti-Pattern rund um das Entwicklungsteam

In vielen Organisationen existiert „Scrum“ eher als Etikett als als wirksam gelebte Praxis. Typische Stolperfallen:

  1. Schein-Selbstorganisation
    • Das Team soll „selbstorganisiert“ sein, wird aber über Scope, Deadlines und Prioritäten von außen gesteuert.
    • Folge: Frustration, Überlastung, „Scrum-Theater“.
  2. Versteckte Hierarchien im Entwicklungsteam
    • Inoffizielle Teamleiter treffen alle technischen Entscheidungen.
    • Juniors beteiligen sich kaum an Schätzungen und Planung.
    • Ergebnis: geringe Ownership und schwache Lernkultur.
  3. Abteilungsdenken statt Produktfokus
    • Strikte Trennung in Frontend-, Backend-, Test-Teams etc.
    • Jedes „Team“ arbeitet im eigenen Sprint, Koordination ist schwierig.
    • Der Kunde bekommt am Ende trotzdem kein integriertes Produktinkrement.
  4. Unvollständige Teams
    • Kritische Kompetenzen (z. B. UX, Test, Betrieb) sitzen außerhalb des Entwicklungsteams.
    • Das Team ist permanent abhängig von anderen Abteilungen.
    • Lieferfähigkeit und Qualität leiden.
  5. Fokus auf Auslastung statt Wert
    • Management steuert primär nach Auslastungsgrad einzelner Personen.
    • Kontextwechsel, Task-Switching und Nebenprojekte zerstören Flow und Produktivität.

Wer diese Muster früh erkennt und adressiert, erhöht die Chance, dass das Entwicklungsteam seinen Kernzweck erfüllt: regelmäßig echten Business-Nutzen zu liefern.


Erfolgsfaktoren für ein wirksames Entwicklungsteam

Aus der Praxis lassen sich einige wiederkehrende Erfolgsfaktoren ableiten:

1. Klarer, stabiler Auftrag

2. Selbstorganisation mit Leitplanken

3. Gemeinsame Definition of Done

4. Technische Exzellenz

5. Transparenz und Datenbasis

6. Psychologische Sicherheit


Praxisbeispiel: Entwicklungsteam in einem B2B-IT-Projekt

Ein anonymisiertes Beispiel aus einem IT-Projekt in einem B2B-Umfeld:

Ausgangslage

Umstellung auf Scrum mit klarem Entwicklungsteam

Effekte nach ca. 4–5 Sprints

Das Beispiel zeigt: Der Mehrwert liegt nicht im Etikett „Scrum“, sondern in einem starken Entwicklungsteam, das Verantwortung übernehmen darf und kann.


Häufige Fragen zum Entwicklungsteam im Scrum

Was ist ein Entwicklungsteam im Scrum in einem Satz?
Ein Entwicklungsteam im Scrum ist die Gruppe von Fachleuten (Developers) im Scrum Team, die selbstorganisiert dafür verantwortlich ist, am Ende jedes Sprints ein fertiges, nutzbares Produktinkrement zu liefern.

Wie viele Personen sollte ein Entwicklungsteam haben?
In der Praxis bewährt sich eine Größe von etwa 3 bis 8 Entwickelnden, abhängig von Produkt und Kontext. Das gesamte Scrum Team (inklusive Product Owner und Scrum Master) sollte dabei etwa 3 bis 10 Personen umfassen.

Gibt es das Entwicklungsteam im aktuellen Scrum Guide noch?
Der Begriff „Entwicklungsteam“ wurde im Scrum Guide 2020 durch „Developers“ im Scrum Team ersetzt.[1][2] Die zugrunde liegende Verantwortlichkeit – ein interdisziplinäres, selbstorganisiertes Lieferteam – bleibt erhalten.

Gehören Tester, UX-Designer oder Analysten auch zum Entwicklungsteam?
Ja, sofern sie aktiv an der Erstellung des Produktinkrements arbeiten. Scrum unterscheidet nicht mehr in Unterrollen wie „Tester“ oder „Designer“ – alle, die an der Wertschöpfung mitarbeiten, werden als Developers verstanden.

Ist ein Projektleiter Teil des Entwicklungsteams im Scrum?
In einem sauberen Scrum-Setup gibt es keinen klassischen Projektleiter als Steuerungsinstanz im Team. Verantwortung für Scope und Priorisierung liegt beim Product Owner, Verantwortung für Arbeitsweise und Lieferung beim Entwicklungsteam.

Kann ein Entwicklungsteam mehrere Produkte gleichzeitig bearbeiten?
Theoretisch ja, praktisch ist das selten empfehlenswert. Jedes zusätzliche Produkt erhöht Kontextwechsel, Komplexität und Koordinationsaufwand. Für Fokus und Wertschöpfung ist ein klares, priorisiertes Produkt in der Regel sinnvoller.


Fazit Entwicklungsteam im Scrum: Was Entscheider jetzt tun sollten

Für Führungskräfte, Projektleiter und Verantwortliche in IT- und Fachbereichen ist das Verständnis des Entwicklungsteams im Scrum zentral. Nur wenn klar ist, wer im Team wofür Verantwortung trägt und wie ein solches Team aufgestellt sein sollte, kann Scrum seinen Mehrwert entfalten.

Konkrete nächste Schritte können sein:

Wenn Sie die Einführung oder Weiterentwicklung von Scrum strukturiert angehen und Ihr Entwicklungsteam gezielt stärken möchten, kann eine externe, pragmatische Begleitung sinnvoll sein. Die Beraterinnen und Berater der PURE Consultant unterstützen Organisationen genau dabei: Rollen klären, Teams befähigen, und Scrum so zuschneiden, dass es in Ihrem Umfeld nachhaltig wirksam wird.

Weitere Einträge