Projekt-Praktikum: Karten-Nachschlag (Update)

Bärbel de BouvierUpdate: Wer sagt denn, dass man im Internet nichts lernen würde? Kommentator Markus Hippeli macht darauf aufmerksam, dass ich bei der Aufwandsschätzung einem Mißverständnis aufgesessen bin. Mehr dazu in seinem Kommentar unter diesem Beitrag. Danke für diesen Hinweis (und sorry Chef!). Ich habe die entsprechenden Passagen nun geändert.

Im letzten Beitrag habe ich kurz das Thema Zeitplanung in Scrum-Projekten mittels eines Kartenspiels angesprochen. Die Frage ist natürlich, warum die Zeitplanung per Kartenspiel besser funktionieren sollte, als ohne. Die Antwort ist ganz einfach: Die Schätzungen werden genauer!

In einer perfekten Welt mit perfekten Menschen wären solche Karten natürlich nicht notwendig. Aber Menschen sind halt Menschen und deshalb brauchen sie Hilfsmittel, die eine Diskussion zum einen schnell auf den Punkt bringen, zum anderen jeden dazu zwingen mitzumachen und über ein gegebenes Thema mit gegebener Ernsthaftigkeit nachzudenken. Für die Aufwandsschätzung in agilen Projekten helfen eben die Planning-Poker-Karten. Und so funktioniert es:

Im Sprint-Planning-Meeting stellt der Product-Owner die einzuschätzende User-Story vor. Danach zückt jedes Team-Mitglied die Karte, deren Wert seiner Meinung nach dem entsprechenden Aufwand entspricht. Ist also ein Team-Mitglied der Meinung, die Userstory erfordert einen Aufwand von „5“, zückt er die entsprechende Karte.

Weiterlesen

Projekt Praktikum: Zeigt her eure Karten!

Bärbel de BouvierHeute habe ich das folgende, sehr stimmungsvolle Video über den Einsatz von Scrum in der Praxis gefunden. Man sieht darin vor allem drei Dinge:

  1. Offenbar macht die Arbeit mit Scrum Spaß.
  2. Scrum ist alles andere als planlos und erfordert einiges an Papierkram.
  3. Kartenspielen ist Arbeit.

Letzter Punkt ist besonders interessant, denn es geht hier um das so genannte Scrum Planning-Poker. Hierbei benutzt man ein Kartenspiel als Diskussionshilfe bei der Schätzung des Aufwands einzelner User-Stories. Anstatt dass die Team-Mitglieder wild spekulierend ihre Aufwandsschätzungen in den Raum schreien, zeigen sie statt dessen Spielkarten, die je nach ihrem Wert, einer bestimmten Zeitspanne entsprechen.

Weiterlesen

Ein wenig Meditation über Scrum

Bärbel de BouvierWir hatten auf diesem Blog schon einmal eine schöne Präsentation von Jurgen Appelo vorgestellt. Jetzt ist mir beim Stöbern auf Slideshare eine weitere über den Weg gelaufen. Wer wissen will, was Scrum ist und wie es funktioniert, findet in der kurzweiligen Slidehow mit dem schönen Titel „The Zen of Scrum“ alles, was er wissen muss. Wer tiefer einsteigen will, findet hingegen bei uns jede Menge wissenswertes zu Scrum.

Ãœbrigens: Zen steht für einen „Zustand meditativer Versenkung“. Wenn’s hilft, dann bitte sehr…


        

Projekt-Praktikum: Die Dauer eines Sprints

Bärbel de BouvierNach dem Product-Backlog-Meeting steht das erste Sprint-Planning-Meeting auf der Agenda. Erster Punkt dort ist die Definition der Dauer eines Sprints. Auf den ersten Blick scheint die Sache ganz klar zu sein: Ein Sprint in Scrum dauert in der Regel 30 Tage. Doch das ist logischerweise nur eine Empfehlung. Abhängig vom Projekt und vom Team kann die Sprintlänge variieren. Es gibt Teams, die mit Sprints von ein oder zwei Wochen Länge arbeiten, andere wiederum bevorzugen bis zu sechs Wochen.

Wonach richtet sich also die Sprintlänge? Ganz einfach: Am Ende jedes Sprints muss ein „shipable Product“, also ein auslieferungsfähiges Produkt stehen. Das wiederum ist aber nicht zu verwechseln mit dem „fertigen“ Produkt. Es geht nur darum, dass ein bestimmtes, funktionierendes Featureset einsatzbereit ist. Egal, wie grundlegend seine Funktionalität ist.

Dementsprechend hängt die Sprintlänge also von der Größe und den Fähigkeiten des Teams ab, sowie von den User-Stories, sprich den zu verwirklichenden Features. Eine Website wird beispielsweise eher in kürzeren Sprints zu bewerkstelligen sein. Ein komplexes Produkt, bei dem komplizierte Entwicklungsprozesse und umfangreiche Vorarbeiten und Learnings nötig sind, wird eher in längeren Sprints angegangen werden.

Ein weiterer, nicht zu vernachlässigender Aspekt der Sprintlänge ist der damit verbundene Overhead. Je kürzer der Sprint, desto häufiger fallen beispielsweise die obligatorischen Sprint-Planning- und Sprint-Review-Meetings an. Gerade bei größeren Teams ist der damit zusätzlich verbundene Aufwand nicht zu unterschätzen.

Grundsätzlich aber gilt: Die Länge des Sprints wird weder vom Management, noch vom Product-Owner vorgegeben. Vielmehr bestimmt sie das Team selbst. Schließlich ist das ja einer der Scrum-Grundgedanken: Das Team weiß am besten, wie es die gestellten Aufgaben bewerkstelligen kann. Bei meinem kleinen und übersichtlichen Projekt hat sich das Team für einwöchige Sprints entschieden.