Vertraue der Macht – Schätzen ohne Bezugssystem

Ein große Herausforderung für Teams in neuen Projekten ist die initiale Schätzung der anstehenden Aufgaben. Selbst wenn man eine abstrakte Einheit wie Story Points zur Bewertung der Größe von Aufgaben heranzieht, ist die erste Schätzung alles andere als trivial. Ich habe festgestellt, dass gerade Planning Poker für die erste Schätzung nur sehr eingeschränkt geeignet ist.

Planning Poker ist eine gute Methode, um Schätzungen für Aufgaben zu ermitteln, wenn in den Domänen und Technologien bereits Wissen vorhanden ist. Gerade am Anfang eines Projektes gibt es aber genau dieses Wissen oft nicht und Teams tun sich schwer, diese Schätzungen für einzelne Items abzugeben. In solchen Situationen hat es sich bewährt, Aufgaben nur relativ zueinander zu schätzen und das Bezugssystem erst im Nachhinein festzulegen. Da Story Points eine abstrakte Einheit sind, die nicht mit einem festen Faktor in andere Einheiten umgerechnet werden kann, ist das problemlos möglich.
Vertraue der Macht – Schätzen ohne Bezugssystem weiterlesen

Einheit Story Points?

Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.
Einheit Story Points? weiterlesen

User Stories der Größe 1

Nach der Agile World hatte ich mit einem Artikel über Schätzereien begonnen, eine Diskussion auf der diesjährigen Agile World auszuwerten. Heute möchte ich den angekündigten zweiten Artikel präsentieren, der sich mit der Frage beschäftigt: Wie praktikabel sind absolute Aussagen?

Im Zusammenhang mit dem Verzicht auf Schätzen hat mich die Aussage, dass User Stories, die größer als 1 sind, generell nicht funktionieren, am meisten erstaunt. Ich halte solche pauschalen Aussagen für zu kurz gedacht. Unabhängig davon, in welchem System man sich bewegt. Eine absolute Größe ohne Bezugssystem ist für eine Schätzung nicht zu gebrauchen.
User Stories der Größe 1 weiterlesen

Schätzereien

Auf der Agile World hatte ich in diesem Jahr eine extrem spannende Diskussion zum Thema Schätzen.
Es ging im Wesentlichen um drei Fragen:
1. Ist Schätzen sinnvoll?
2. Wie praktikabel sind absolute Aussagen?
3. Sind Schätzgrößen einheitenlos?

Meine Gedanken zu diesen drei Fragen möchte ich hier noch einmal zusammenfassen – vielleicht sind sie ja für andere nützlich, die in ähnliche Diskussionen verwickelt werden.
Schätzereien weiterlesen

Oliver Hummel: Aufwandsschätzungen kompakt

Oliver Hummel: Aufwandsschätzungen kompakt
Oliver Hummel: Aufwandsschätzungen kompakt

Oliver Hummel legt mit Aufwandsschätzungen kompakt eine gelungene Übersicht gängiger Methoden zur Aufwandsschätzung und Projektplanung.
Besonders erfreulich für mich war der Einstieg mit Story Points, wenngleich man merkt, dass der Autor hier wenig Praxiserfahrung mitbringt. Die Kalulation von Netto-Arbeitsstunden für Sprints ist mittlerweile überholt. Aber für das agile Schätzen hat ja bereits Mike Cohn ein Buch geschrieben. Die im einführenden Kapitel vorgestellten Schätztechniken, wie die einfache Zwei- oder Drei-Punkt-Schätzung sowie Schätzungen auf Basis von Analogien sind gut erklärt und für Softwareentwickler hilfreich.

Einen großen Teil nimmt das Kapitel zur Einschätzung von Komplexität des zu entwickelnden Systems ein. Neben Function Points in verschiedenen Varianten erklärt der Autor auch ähnlichen Modelle wie Object Points nach Banker, Use Case Points und die speziell für Web Applikationen geeigneten Web Objects. Die Einführung in diese Schätzmethoden ist sehr hilfreich und übersichtlich, die Methoden an sich halte ich aber im Projektalltag für wenig tauglich. Der Autor beruft sich auf verschiedene Statistiken, die die Zuverlässigkeit der einzelnen Methoden beweisen, das Problem des Vorausplanens bleibt aber bestehen. Alle Methoden gehen von der Annahme aus, dass ein Projekt eine vorangestellte Planungsphase haben kann, in der die Anforderungen detailliert beschrieben werden können, um auf dieser Basis Schätzungen zu erstellen.

Zur tatsächlichen Aufwandschätzung werden die Methoden COCOMO und SLIM vorgestellt. Beide Methoden können auf Basis einer Komplexitätsschätzung, z.B. auf Basis von Function Points und einer Umrechnungstabelle in Lines of Code, den voraussichtlichen Aufwand für ein Projekt kalkulieren. Die Formeln erscheinen mir sehr willkürlich, kritische Geister werden hier wohl in der Originalliteratur recherchieren.

Im Kapitel über die eigentliche Projektplanung geht der Autor leider nur von klassischen Wasserfallprojekten aus. Ob die heute irgendwo überhaupt noch stattfinden, sei dahingestellt. Eine Gegenüberstellung mir Mike Cohns agiler Projektplanung hätte an der Stelle das Buch rund gemacht. Ein Kapitel mit Praxistipps für Projektallags, zur Kommunikation und Verhandlung von Aufwandsschätzungen, Werkzeugen zur Unterstützung des Schätzens und einer kompakten Übersicht schließen das Buch ab.

Lesenswert machen das Buch die Ausflüge zu Tom DeMarco, Parkikson’s Law, Todesmarsch-Projekten und andere anekdotische Darstellungen. Das Buch ist flüssig geschrieben und gibt Entwicklern einen guten Überblick der Materie.
Zur Anwendung der komplexen Schätzverfahren benötigt man aber viel Erfahrung.

Der Autor bietet auch eine Website mit Korrekturen und vielen interessanten Links zum Buch.

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning
Mike Cohn: Agile Estimating and Planning

Wer immer wieder Projekte sieht, in denen das Chaos regiert, in denen die Projektleitung nur reagiert statt zu steuern, dem sei Mike Cohns Agile Estimating and Planning ans Herz gelegt. Ein Buch, das dem Leser eine neue Perspektive darauf gibt, wie Projekte funktionieren können, wenn man nur endlich beginnt, Projekte und ihre Plannung besser zu verstehen.

Das Buch macht einem Lust darauf, Projekte nur noch agil zu planen. Zwar merkt man Cohns deutliche Vorliebe für User Stories und Scrum, aber die Ideen und Konzepte aus diesem Buch sind auch Problemlos mit anderen Methoden des Requirement Engineering oder agilen Vorgehensweisen kompatibel.

Zum Einstieg erfährt der Leser, warum Planung notwendig ist und warum sie so oft daneben liegt. Aus den Gründen für letzteres leitet Cohn ab, dass Planung eigentlich nur agil funktionieren kann – eine Erkenntnis der man unweigerlich zustimmen muss, wenn man neben der agilen auch die Welt des V-Modells kennt.

Im zweitel Teil des Buches nimmt Cohn dem Leser die Angst, zu schätzen. Es wird klar, dass Schätzen inhärenter Bestandteil von Planung ist und die einzige Möglichkeit, besser zu planen, darin besteht, besser zu schätzen. Dazu muss man mit dem Schätzen allerdings erst einmal beginnen. Mit echtem Schätzen, versteht sich. Cohn erklärt, wie man im Team schätzen kann, wann man neu schätzen muss und wann Story Points oder Ideal Days die bessere Grundlage sind.

Der dritte Teil des Buches geht auf die Fragen ein, anhand welcher Werte man priorisieren sollte. Steht das Budget im Vordergrund? Oder eher die Funktionalität? Man erfährt, wie man beides gewichten kann und den Kunden zufrieden stellt. Zum Abschluss des dritten Teils erfährt der Leser noch einiges wichtige über das Splitten von Stories, wie man anhand von Datenstrukturen, Geschäftsprozessen oder Cross-Cutting-Concerns splittet um ein Projekt beherrschbar – und damit planbar – zu machen.

Wie man einen agilen Plan mit einer Zeitplanung versieht, wird im vierten Teil des Buches erklärt. Ausgehend vom Release-Plan geht es zum Plan für Iterationen, entweder basierend auf der Velocity oder basierend auf Commitments. Auch die Unterschiede zwischen Release- und Iterationsplan werden erklärt. Interessant ist auch das Thema Schätzen der Verlocity und wie man in agilen Plänen mit Puffern umgeht. Ein kurzes Kapitel widment sich der Frage, wie man agile Pläne für Projekte mit mehr als einem Team aufstellen kann.

Da auch in agilen Projekten gefragt wird, wie weit das Projekt den voran gekommen ist, erklärt Cohn im fünften Teil des Buches, wie man Release- und Iterationsplänge beobachten kann und Maßnahmen ableitet. Es wird auch darauf eingegangen, wie man über und mit agilen Plänen kommuniziert. Die beiden letzten Teile widmen sich zum einen der Frage, warum agile Planung funktioniert und einer Fallsstudie zum Thema agile Planung.

Fazit: Agile Estimating and Planning ist die konsequente Fortsetzung von User Stories Applied. Wer Projekte plant, egal ob agil oder klassisch, für den ist dieses Buch ein Muss.

Schätzungen im Sprint-Planning

Lohnt es sich, im Sprint-Planning Stunden für Tasks zu schätzen?
Die Frage diskutiere ich immer wieder mit Teams, denn in der Regel ist es eines der ersten Dinge, die ich Teams abgewöhne. Der Verzicht auf die Schätzung von Stunden für einzelne Tasks im Planning führt eigentlich immer zu einem besseren weil fokussiertem Planning.

Warum man die Stundenschätzung nicht unbedingt benötigt und warum das Planning dadurch häufig besser wird, will ich im Folgenden erklären.
Schätzungen im Sprint-Planning weiterlesen