projektManagementaktuell | AUSGABE 1.2015 58 WISSEN vorgestellt, um bei vielen Storys im Team schnell zu einem Ergebnis zu kommen. Dazu zählt etwa „Magic Estimation.“ Bei diesen Techniken finden sich einige Elemente wie sie aus den verschiedenen Varianten von Delphi und der Schätzklausur bekannt sind, so zum Beispiel die Praxis, dass sehr unterschiedliche Bewertungen durch einzelne Teammitglieder auf Diskussions- und Klärungsbedarf bei der jeweiligen User Story hinweisen. Die Schätzsitzungen werden vor jedem Sprint Planning durchgeführt, um zu einem aktualisierten und geschätzten Product Backlog zu kommen. Die ursprünglichen Schätzungen werden überprüft und neu hinzugekommene User Storys geschätzt. Gloger empfiehlt solche Sitzungen mindestens einmal pro Sprint, idealerweise aber zweimal pro Sprint durchzuführen. Verglichen mit Prozeduren des „klassischen“ Projektmanagements ist das natürlich ein enormer Fortschritt, der allerdings voraussetzt, dass sich der jeweils damit verbundene Aufwand in Grenzen hält. Das verspricht Gloger. Er fordert, dass solche Treffen nicht länger als 35 Minuten dauern dürfen. Eine interessante Anwendung der Story Points bringt der Autor schließlich noch am Schluss unter der Überschrift „Die Velocity ermitteln - das Schätzen überflüssig machen“. Er führt das Denken in Zykluszeiten ein. Gemessen soll werden, „wie lange es dauert, eine User Story vollständig zu liefern“. Dazu wird - grob gesagt - für jede dieser Einheiten das Eintrittsdatum in das Committed Product Backlog und das Lieferdatum registriert und dann aus zahlreichen derartigen Werten ein Trend errechnet. Auch wenn Gloger flott schreibt, macht er es einem Rezensenten nicht ganz leicht. Seinem Text entnehme ich, dass das auch anderen so geht. Ich bin mir deshalb nicht ganz sicher, ob ich wirklich alles verstanden habe. Vielleicht bin ich für agil auch schon etwas zu alt und zu wenig agil. In einem Punkt hat mich der Autor nicht überzeugt: Dass nämlich Aufwandsschätzungen durch seinen Ansatz überflüssig werden. So oder so: Das Buch ist es auf jeden Fall wert, gelesen und diskutiert zu werden. Heinz Schelle nicht eingeht. (Die Anwendung von Function Point in der agilen Entwicklung wird z. B. bei D. Horvath, Function Point Analysis and Agile Methodology; www.qpmg.com/ pdf/ articles/ Function_Point_ Analysis_and_Agile_Methodology.pdf beschrieben). Heute ist Functional Size Measurement in der ISO-Norm ISO/ TEC 20926 standardisiert. Im Unterschied zu dieser Methode, die im Lauf der Jahre immer mehr verfeinert wurde und die viele Varianten hat (vgl. dazu die Besprechung des Werks von M. Bundschuh und C. Dekkers in Heft 3/ 2009), geht aber Gloger nicht von relativ abstrakt beschriebenen, klassifizierten Funktionen aus, sondern wählt als Planungseinheit die sehr viel konkreteren User Storys. Diese Storys, für deren Formulierung präzise Anleitungen gegeben werden, kommen in das Product Backlog. Dort werden sie in unterschiedlichen „Körben“, d. h. Kategorien (S, M, L: klein, mittelgroß oder groß), abgelegt. Innerhalb dieser „Körbe“ werden sie nochmals unterteilt in klein, mittel oder groß, sodass sich insgesamt neun Kategorien von Größen ergeben. Diesen Gruppen werden dann neun Rangziffern (z. B. 1, 2, 3, 5, 8, 13, 20, 40, 100; Beispiel Gloger) zugewiesen. Diese Story Points, wie sie auch abgekürzt genannt werden, werden allerdings nicht wie bei Function Point für Aufwandsschätzungen (etwa in Personenmonaten) verwendet. Das lehnt Gloger mit einigen Argumenten nahezu kategorisch ab, wobei er nicht vergisst, zu erwähnen, dass viele damit Probleme haben. Die vorgebrachten Gründe für die Schätzung der Produktgröße mithilfe der Story Points sind durchaus plausibel. Mir leuchtet allerdings nicht ein, warum sie nicht auch zumindest als Hilfsgrößen für die Aufwandsschätzung benutzt werden. Der Verfasser gesteht allerdings später dann doch zu, dass in der Praxis der Wunsch nach Aufwandsschätzungen durchaus berechtigt ist. Er will sie allerdings nur auf der Projektebene, also lediglich sehr global durchführen lassen und zwar mithilfe der Analogieschätzung, d. h. mithilfe der Orientierung an einem bereits abgeschlossenen Projekt. Im Anschluss an die prinzipielle Erläuterung der Story Points werden dann verschiedene Methoden Gloger, B.: Wie schätzt man in agilen Projekten - oder wieso Scrum-Projekte erfolgreicher sind. Extra: mit kostenlosem E-Book. Carl Hanser Verlag, München 2014, ISBN 978- 3-446-43910-8, 148 S., EUR 29,99 (D) Der Titel des Buches ist ein wenig irreführend. Es geht im Werk von Gloger nicht nur um Schätzung in Projekten. Vielmehr wird eine ganze Reihe von anderen Aspekten erläutert. So geht der Verfasser zum Beispiel ausführlich auf die Rolle des Product Owners und auf andere Rollen ein, beschreibt die Projektphasen der agilen Produktentwicklung, stellt den Zusammenhang zum Design Thinking her und schildert Tools und Techniken während der Implementierung, so insbesondere natürlich die Methodik der User Story und das Product Backlog. Am Schluss wird auch noch ausführlich die Planung und Durchführung größerer Projekte mit Scrum dargestellt. Das ist allerdings keine teilweise Themaverfehlung, sondern ist unumgänglich, um die Schätzmethodik zu verstehen. Alles ist sehr gut lesbar und flott formuliert. Hervorheben möchte ich dabei speziell die vielen praktischen Tipps, die der Autor immer wieder einstreut. Besonders interessant ist natürlich die vom Verfasser ausführlich geschilderte Schätzmethode. Der Grund ist vor allem, dass sich auf diesem Gebiet nach Meinung des Rezensenten seit vielen Jahren kaum mehr etwas getan hat. Noch immer wird in der Lehrbuchliteratur, wenn überhaupt, auf die in der Firma Siemens entwickelte Schätzklausur bzw. auf eine von Barry W. Boehm (Software Engineering Economics) empfohlene Methode (Breitband-Delphi) zurückgegriffen. Weiterentwicklungen sind für mich bisher kaum erkennbar. Gloger geht von der Funktionalität des zu entwickelnden Produkts aus. Das ist natürlich nicht neu. Schon Ende der 70er-Jahre wurde von Allen J. Albrecht bei IBM für die Schätzung von Entwicklungskosten bei Softwareprojekten Function Point entwickelt, worauf der Autor allerdings Wieso Scrum-Projekte erfolgreicher sind