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, das Team und der Scrum Master beteiligt. Der Product Owner erläutert die Anforderungen und beantwortet Fragen des Teams in Bezug auf die Anforderungen. Das Team schätzt den Aufwand, da es später ja auch für die Realisierung verantwortlich ist. Der Scrum Master moderiert die Veranstaltung. Die Schätzung ist eine reine Teamschätzung, d.h. der Product Owner und der Scrum Master schätzen selber nicht. Da alle Rollen bei der Schätzung beteiligt sind, ist das Verfahren sehr transparent.

Die Schätzrunden sind ermüdend und deshalb zeitlich begrenzt: Während man durchaus die ganze Nacht pokert, sollten die einzelnen "Runden" beim Planungspoker nur etwa zwei Stunden dauern (Pichler, 2008).

Dass die Entwickler den Aufwand für die Entwicklung schätzen, ist keinesfalls eine Erfindung der agilen Softwareentwicklung. Die Anwendung dieses Prinzips erfolgt auch in Projekten, die nicht nach einem agilen Vorgehen ablaufen – denn die ausführenden Stellen geben immer noch die präzisesten Werte bei der Aufwandsschätzung ab.

User Storys

Im Product Backlog werden die funktionalen und nicht-funktionalen Anforderungen in Form von sog. User Storys erfasst (vgl. Cohn, 2004 sowie "Agile Softwareentwicklung mit Scrum und User Stories", Projekt Magazin 02/2010). Eine User Story beschreibt ein Feature, das eine zukünftige Anwendung enthalten soll. Weit verbreitet ist die Verwendung von Schablonen bei der Formulierung von User Storys. Häufig wird hierbei die Form verwendet: Als <Rolle des Anwenders> möchte ich <die gewünschte Möglichkeit>, sodass <Geschäftswert>. Die User Story wird häufig um die Beschreibung von Akzeptanztests ergänzt, mit denen die Implementierung der User Story getestet werden soll.

Story Points

Beim Planning Poker wird nicht geschätzt, wie hoch der Aufwand zur Realisierung der User Storys (in Zeiteinheiten) sein wird. Stattdessen schätzt man die relative Größe von User Storys zueinander. Die hierfür verwendete Maßeinheit wird als "Story Point" bezeichnet. Schätzt man 1 Story Point für die Realisierung einer User Story A und 3 Story Points für die Realisierung einer User Story B, bedeutet dies, dass der Zeitaufwand für die Realisierung von B vermutlich drei mal so groß sein wird wie für die Realisierung von A.