Scrum Guide

Der umfassende Leitfaden zu Scrum: Events, Rollen, Artefakte und Best Practices

Developers / Entwicklungsteam

Die Developers (bis 2020: Entwicklungsteam) sind die Fachleute, die in jedem Sprint ein wertvolles Produktinkrement liefern. Das cross-funktionale, selbstorganisierte Team trägt kollektive Verantwortung für Qualität und Ergebnis – ein fundamentaler Unterschied zu klassischen Projektteams.

Verantwortlichkeiten

  • Das Produktinkrement in jedem Sprint erstellen
  • Qualität des Inkrements sicherstellen
  • Selbstorganisation des Teams
  • Technische Entscheidungen treffen
  • Sprint Backlog verwalten
  • Fortschritt transparent machen
  • Kontinuierliche Verbesserung

Wichtige Skills

  • Cross-funktionale Expertise
  • Selbstorganisation
  • Technische Kompetenz
  • Kollaboration
  • Problemlösung
  • Qualitätssicherung
  • Agile Methoden

Herausforderungen

  • Cross-funktionales Arbeiten etablieren
  • Selbstorganisation in hierarchischen Strukturen
  • Technische Schulden reduzieren
  • Balance zwischen Geschwindigkeit und Qualität

Erfolgsmetriken

  • Stabile Lieferung von Inkrementen
  • Hohe Code-Qualität
  • Team-Zufriedenheit
  • Effektive Zusammenarbeit
  • Kontinuierliche Verbesserung
Self-Managed Teams nach Hackman

Entwicklungsteams sind self-managed und organisieren ihre Arbeit eigenständig

Entwickler in Scrum Events

Die Entwickler sind in allen Scrum Events aktiv beteiligt und bringen ihre technische Expertise ein:

Sprint Planning

Schätzen den Aufwand der Product Backlog Items. Entscheiden gemeinsam, welche Items sie in den Sprint nehmen können. Erstellen den technischen Plan (Sprint Backlog) für die Umsetzung. Stellen Fragen zur Funktionalität und klären technische Abhängigkeiten.

Daily Scrum

Organisieren täglich ihre Arbeit eigenständig. Synchronisieren sich über Fortschritt und nächste Schritte. Identifizieren Impediments und suchen gemeinsam Lösungen. Das Daily Scrum ist IHR Meeting – für Entwickler, von Entwicklern geführt.

Sprint Review

Demonstrieren das fertige Inkrement den Stakeholdern. Erklären technische Entscheidungen und Herausforderungen. Sammeln Feedback zur Funktionalität. Diskutieren mit dem Product Owner über nächste Schritte.

Sprint Retrospective

Reflektieren ihre Zusammenarbeit und Prozesse. Identifizieren Verbesserungspotenziale in Technik und Workflow. Entwickeln konkrete Maßnahmen für bessere Team-Performance. Nehmen Ownership für Verbesserungen im nächsten Sprint.

Product Backlog Refinement

Helfen dem Product Owner, Items zu verfeinern und zu klären. Schätzen den Aufwand und identifizieren technische Risiken. Schlagen alternative technische Ansätze vor. Splitten zu große Stories in handhabbare Items.

Was bedeutet "cross-funktional"?

Ein cross-funktionales Entwicklungsteam hat alle Fähigkeiten, die nötig sind, um ein Produktinkrement zu erstellen – ohne auf externe Abhängigkeiten angewiesen zu sein.

Cross-funktional bedeutet:

  • Vielfältige Skills: Frontend, Backend, Testing, UX, DevOps – alles im Team
  • Keine Silos: Keine "Frontend-Leute vs. Backend-Leute", sondern gemeinsames Team
  • T-Shaped Skills: Tiefes Wissen in einem Bereich + Grundwissen in anderen
  • Gemeinsame Ownership: Alle sind für das Inkrement verantwortlich, nicht nur "ihr Teil"
  • Lernen und wachsen: Teammitglieder erweitern kontinuierlich ihre Skills

Wichtig: Cross-funktional heißt NICHT, dass jeder alles können muss. Es bedeutet, dass das Team als Ganzes alle nötigen Fähigkeiten hat und gemeinsam Verantwortung übernimmt.

Selbstorganisation im Entwicklungsteam

Selbstorganisation ist ein Kernprinzip von Scrum. Das Entwicklungsteam entscheidet eigenständig, wie es seine Arbeit organisiert und durchführt:

  • Wer arbeitet woran: Team entscheidet gemeinsam, keine Zuweisung von außen
  • Wie wird es umgesetzt: Technische Entscheidungen liegen beim Team
  • Wie wird getestet: Team definiert Qualitätsstandards und Testing-Strategie
  • Wie wird zusammengearbeitet: Team findet eigene Arbeitsweisen und Tools
  • Wie wird verbessert: Team identifiziert und implementiert Verbesserungen

⚠️ Häufiges Missverständnis

Selbstorganisation bedeutet NICHT "jeder macht was er will" oder "keine Abstimmung nötig". Es bedeutet: Das Team organisiert sich gemeinsam und kollaborativ, ohne dass ein Manager detaillierte Anweisungen gibt.

Optimale Team-Größe

Der Scrum Guide empfiehlt 3-9 Entwickler pro Team (plus Scrum Master und Product Owner). Warum diese Größe?

Zu klein (<3)

  • → Fehlende Skills im Team
  • → Hohe Abhängigkeit von Einzelpersonen
  • → Geringe Produktivität bei Urlaub/Krankheit
  • → Limitierte Problemlösungsfähigkeit

Zu groß (>9)

  • → Koordinationsaufwand steigt exponentiell
  • → Daily Scrum dauert zu lange
  • → Schwierig, echte Team-Einheit zu bilden
  • → Individuelle Verantwortung verwässert

Sweet Spot: 5-7 Entwickler – groß genug für diverse Skills, klein genug für effektive Kommunikation.

Wie werde ich Teil eines Scrum-Teams?

Als Entwickler in einem Scrum-Team zu arbeiten erfordert sowohl technische Kompetenz als auch agile Mindset:

  • Technische Grundlagen: Solide Fähigkeiten in deiner Disziplin (z.B. Softwareentwicklung, Testing, UX). Diese sind Voraussetzung.
  • Agile Prinzipien lernen: Verstehe Scrum und agile Werte. Viele Entwickler starten mit einer Scrum Schulung.
  • Kollaboration üben: Lerne, im Team zu arbeiten statt als Einzelkämpfer. Pair Programming, Code Reviews und offene Kommunikation sind wichtig.
  • T-Shaped Skills entwickeln: Vertiefe deine Expertise, aber lerne auch andere Bereiche kennen (z.B. als Backend-Dev auch Frontend-Basics).
  • Ownership mindset: Denke in "unser Produkt" statt "mein Code". Verantwortung wird geteilt, Erfolg ist Team-Erfolg.

🎯 Nächster Schritt

Möchtest du in einem agilen Team arbeiten oder dein bestehendes Team verbessern? In unseren Scrum Trainings lernst du, wie cross-funktionale Teams erfolgreich zusammenarbeiten.

Scrum Training ansehen

Nächste Schritte

Möchtest du mehr über diese Scrum-Rolle lernen oder sie selbst ausüben?

Developers / Entwicklungsteam - Podcast-Folgen

#26: Developers in Scrum – Selbstorganisation & Verantwortung

Developers (früher Development Team) in Scrum: Selbstorganisation, kollektive Verantwortung, nicht wie Projektteams. Strukturelle Unterschiede verstehen.

Zur Episode

#121: Agilität im Jahr 2022

Agilität steht am Scheideweg zwischen Verflachung und Professionalisierung. Erfahre, wie ehrlicher Austausch und Fokus auf interne Kapazitäten nachhaltige Transformationen ermöglichen.

Zur Episode

#122: Auftragsklärung als Scrum Master & Agile Coach

Scrum Master und Agile Coaches fallen oft in die Kümmerer-Falle. Erfahre, wie eine klare Auftragsklärung dir Orientierung gibt und deine Wirkung maximiert.

Zur Episode

#115: Statt auf bessere Anforderungen zu pochen, sich besser zu mäßigen Anforderungen aufstellen

Warum perfekte Anforderungen Scrum-Teams lähmen und wie du mit einem 3-Säulen-Modell zu leichtgewichtiger, effektiver Zusammenarbeit findest. Für Scrum Master und Product Owner.

Zur Episode

Häufig gestellte Fragen zu Developers / Entwicklungsteam

Was zeichnet ein Scrum-Entwicklungsteam im Vergleich zu einem traditionellen Projektteam aus?

Ein Scrum-Entwicklungsteam ist eine selbstorganisierte Einheit, die kollektiv für die Erstellung eines 'Done'-Inkrements verantwortlich ist. Im Gegensatz zu traditionellen Projektteams, die oft von Führungskräften gesteuert werden, organisiert und managt das Entwicklungsteam seine Arbeit eigenständig. Es gibt keine Subgruppen wie separate Test- oder Umsetzungsteams; stattdessen arbeiten alle Mitglieder eng zusammen und teilen eine gemeinsame Rechenschaftspflicht. Das bedeutet, das Team steht und fällt als Ganzes – wenn ein Teammitglied Schwierigkeiten hat, ist es die Verantwortung aller, zu unterstützen. Diese Eigenverantwortung und enge Zusammenarbeit ermöglichen es, bessere Ergebnisse zu liefern, da das Team direkt auf Herausforderungen reagieren und seine Prozesse kontinuierlich optimieren kann, anstatt auf externe Steuerung zu warten.

Warum ist die Selbstorganisation des Entwicklungsteams so zentral in Scrum und wie wird sie unterstützt?

Die Selbstorganisation ist zentral, weil sie dem Team ermöglicht, schnell und flexibel auf Veränderungen zu reagieren und eigenverantwortlich die bestmöglichen Lösungen zu erarbeiten. Im Podcast wird betont, dass das Team im Sprint von niemandem 'ausgesteuert' wird. Stattdessen nutzt es Scrum-Rahmenwerke wie das <a href="/scrum/events/daily-scrum/" className="text-brand-600 hover:text-brand-700 font-medium">Daily Scrum</a> und das Sprint Backlog, um seine Arbeit selbst zu koordinieren. Der Scrum Master unterstützt dabei durch Coaching und hilft, Hindernisse zu beseitigen, anstatt zu micromanagen. Diese Unterstützung fördert die Eigenverantwortung, sodass das Team lernt, seinen Fortschritt kontinuierlich zu überwachen und bei Bedarf nachzusteuern. Praktisch bedeutet das, Tools wie Taskboards zu nutzen, um den Sprint-Fortschritt transparent zu machen und regelmäßig im Team zu reflektieren, wie die Zusammenarbeit verbessert werden kann.

Welche Rolle spielt das Sprint Planning für die Verantwortungsübernahme des Entwicklungsteams?

Das <a href="/scrum/events/sprint-planning/" className="text-brand-600 hover:text-brand-700 font-medium">Sprint Planning</a> ist entscheidend, da hier das Entwicklungsteam aktiv den Umfang der Arbeit für den kommenden Sprint selbst auswählt und sich mit dem Product Owner auf ein sinnhaftes Sprintziel einigt. Dies führt zu einem 'Deal', bei dem das Team zusagt, sein Bestes zu geben, um das Ziel zu erreichen. Dieser Prozess stärkt das Commitment und die Ownership des Teams. Es verpflichtet sich, eigenständig den Fortschritt zu überwachen, bei Problemen frühzeitig den Product Owner einzubinden und notwendige Anpassungen vorzunehmen. Dadurch wird der Product Owner entlastet und kann sich auf die Backlog-Pflege konzentrieren, während das Team die Verantwortung für die Umsetzung übernimmt – eine grundlegende Voraussetzung für erfolgreiche Selbstorganisation und qualitativ hochwertige Ergebnisse. Mehr über die richtige Durchführung findest du im <a href="/scrum/events/sprint-planning/" className="text-brand-600 hover:text-brand-700 font-medium">Sprint Planning Guide</a>.

Warum muss ein Entwicklungsteam über alle notwendigen Fähigkeiten verfügen und was bedeutet das konkret?

Ein Entwicklungsteam muss alle Fähigkeiten besitzen, um ein Backlog-Item von der Idee bis zum fertigen, wertstiftenden Inkrement umzusetzen. Das bedeutet, dass das Team multidisziplinär aufgestellt sein sollte – beispielsweise mit Expertise in Entwicklung, Testing und Design –, um unabhängig arbeiten zu können. Im Podcast wird hervorgehoben, dass es keine speziellen Titel oder Subgruppen geben sollte; stattdessen arbeiten alle Mitglieder eng zusammen und teilen Wissen. Konkret heißt das, dass Teammitglieder bereit sein müssen, sich gegenseitig zu unterstützen und Fähigkeiten zu entwickeln, um Engpässe zu vermeiden. Diese Vollständigkeit ermöglicht es dem Team, schneller und mit höherer Qualität zu liefern, da es nicht auf externe Abteilungen warten muss und eine durchgängige Verantwortung für das Endergebnis trägt.

Wie kann ein Entwicklungsteam effektiv seinen Sprint-Fortschritt überwachen und steuern?

Ein Entwicklungsteam überwacht und steuert seinen Sprint-Fortschritt durch regelmäßige, selbstorganisierte Koordination, primär im <a href="/scrum/events/daily-scrum/" className="text-brand-600 hover:text-brand-700 font-medium">Daily Scrum</a>. Hier bespricht das Team täglich, was seit dem letzten Treffen erreicht wurde, was als Nächstes ansteht und welche Hindernisse existieren. Zusätzlich nutzt es visuelle Hilfsmittel wie Taskboards oder Burndown-Charts, um den Fortschritt transparent darzustellen und frühzeitig Abweichungen vom Sprintziel zu erkennen. Der Podcast betont, dass Teams, die diese Verantwortung nicht gewohnt sind, gezielt Tools und Praktiken einführen sollten, um den Gesamtblick zu behalten. Wichtig ist, dass das Team proaktiv nachsteuert – beispielsweise durch Anpassung der Arbeitsweise oder frühzeitige Kommunikation mit dem Product Owner –, um sicherzustellen, dass das Sprintziel erreicht wird, ohne auf externes Micromanagement angewiesen zu sein.

Welche Bedeutung hat die 'Definition of Done' für die Zusammenarbeit im Entwicklungsteam?

Die <a href="/scrum/artefakte/definition-of-done/" className="text-brand-600 hover:text-brand-700 font-medium">'Definition of Done'</a> ist ein gemeinsames, explizites Verständnis darüber, wann ein Arbeitselement als fertig gilt, und sie ist essenziell für die Konsistenz und Qualität der Arbeit. Da ein Scrum-Entwicklungsteam multidisziplinär ist, haben verschiedene Mitglieder oft unterschiedliche Perspektiven auf Fertigstellungs-Kriterien. Eine klare Definition schafft Transparenz und reduziert Missverständnisse in der Planung und täglichen Zusammenarbeit. Sie hilft dem Team, einheitlich zu handeln und sicherzustellen, dass jedes Inkrement potenziell auslieferbar ist. Praktisch sollte das Team die Definition gemeinsam erarbeiten und regelmäßig überprüfen, um sie an sich ändernde Anforderungen anzupassen. Dies stärkt die kollektive Verantwortung und stellt sicher, dass alle Teammitglieder dasselbe Qualitätsniveau anstreben, was zu zuverlässigeren und wertvolleren Ergebnissen führt.

Scrum-Training buchen

Lerne Scrum in der Praxis kennen. Unsere zertifizierten Trainings vermitteln dir das nötige Wissen, um Scrum erfolgreich in deinem Unternehmen einzuführen.

Zu den Trainings