Scrum Entwicklungsteam

Das Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints ein fertiges [„Done“] Inkrement übergeben, welches potenziell auslieferbar ist. Im Sprint Review muss ein fertiges Inkrement vorhanden sein. Nur Mitglieder der Entwicklungsteams erstellen das Produktinkrement.

Entwicklungsteams sind von der Organisation so strukturiert und befähigt, dass sie ihre eigene Arbeit selbst organisieren und managen. Die daraus resultierende Synergie optimiert die Gesamteffizienz und -Effektivität des Entwicklungsteams.

Entwicklungsteams weisen die folgenden Eigenschaften auf:

  • Sie sind selbstorganisierend. Niemand (nicht einmal der Scrum Master) sagt dem Entwicklungsteam, wie es aus dem Product Backlog potentiell auslieferbare Funktionalität erzeugen soll.
  • Entwicklungsteams sind interdisziplinär. Sie haben als Team alle Fähigkeiten, die notwendig sind, um ein Produktinkrement zu erstellen.
  • Scrum kennt für Mitglieder des Entwicklungsteams keine Titel. Dies ist unabhängig von der Arbeit, die diese Personen erledigen.
  • Scrum kennt keine weiteren Unterteilungen innerhalb des Entwicklungsteams, ungeachtet der verschiedenen Themenfelder, mit denen das Team sich befasst, also z.B. „Test“, „Architektur“, „Betrieb“ oder „Analyse“.
  • Einzelne Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzem.

Größe des Entwicklungsteams

Die optimale Größe des Entwicklungsteams ist klein genug, um flink zu bleiben und groß genug, um bedeutende Arbeit innerhalb eines Sprints erledigen zu können. Weniger als drei Mitglieder des Entwicklungsteams reduzieren die Interaktion und führen zu geringeren Produktivitätssteigerungen [als bei größeren Teams]. Kleinere Entwicklungsteams können eventuell kein potentiell auslieferbares Produktinkrement liefern, da sie möglicherweise nicht über alle benötigten Fähigkeiten verfügen. Mehr als neun Mitglieder erfordern zu viel Koordination. Große Entwicklungsteams erzeugen eine zu hohe Komplexität, als dass ein empirischer Prozess nützlich wäre. Product Owner und Scrum Master zählen nicht zu dieser Zahl dazu, sofern sie nicht ebenso die Arbeit aus dem Sprint Backlog erledigen.

Scrum Guide Stand November 2017