Agile Aufwandsschätzung in Scrum

Planning Poker – Techniken, Erfahrungen und Empfehlungen

In agilen Software-Projekten, speziell in Scrum, hat sich zur Aufwandsschätzung in den vergangenen Jahren die Methode des Planning Pokers etabliert. Bei regelmäßiger Anwendung innerhalb eines Teams ermöglicht dieses Verfahren gute Prognosen. Dr. Oliver Linssen stellt in diesem Beitrag die Techniken vor, die für die Durchführung des Planning Pokers in Scrum erforderlich sind und gibt Empfehlungen, worauf Sie beim Einsatz in der Praxis achten sollten.

Unzuverlässige Aufwandsschätzungen in der Softwareentwicklung sind eher der Normalfall als die Ausnahme. Um diesem Problem zu begegnen, sind im Lauf der letzten Jahrzehnte zahlreiche Verfahren zur Aufwandsschätzung in der Software-Entwicklung entstanden. Dabei ist in agilen Projekten das sog. Planungspoker (engl. "Planning Poker") weit verbreitet.

Dieser Beitrag stellt die Techniken und Verfahren vor, die für das Schätzen in Scrum mit Planning Poker erforderlich sind. Darüber hinaus erhalten Sie Empfehlungen, worauf Sie beim Einsatz von Planning Poker in der Praxis achten sollten.

Ziel des Planning Pokers

Der Product Owner erhält durch die Schätzung des Teams Aussagen darüber, wie "teuer" die Realisierung der einzelnen User Storys ist und verwendet diese Schätzungen, um die Einträge im Product Backlog zu priorisieren. Das Team erhält durch die Schätzung eine realistische Grundlage für die Planung der in den Sprints zu realisierenden Features.

Für beide Seiten ist es von Vorteil, dass in Scrum die Schätzung regelmäßig auf der Grundlage neuer Erkenntnisse überarbeitet wird. Dies ist eine wichtige Grundlage dafür, was der Betriebswirtschaftler auch als "rollierende Planung" bezeichnet: Eine gleitende Planung der Perioden in der Zukunft, wobei die nächste Periode konkret und die folgenden Perioden grob geplant werden.

Allgemeines zum Ablauf des Planungspokers

Aufwandsschätzungen finden in Scrum nicht nur zu Beginn des Projekts, sondern während des gesamten Projektverlaufs statt. Vor Beginn des ersten Sprints wird in einer oder mehreren Sitzungen der gesamte Inhalt des Product Backlogs geschätzt. Da sich das Product Backlog während des gesamten Projekts verändert, wird auch in jedem Sprint geschätzt. Dadurch fließen die aktuellen Erfahrungen über Produktivität des Teams, Komplexität der Technik und des Anwendungsgebiets und andere Randbedingungen in die Schätzung ein.

An der Schätzung sind der Product Owner,

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 10 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link