Browse Category

Scrum

Gastbeitrag: Die magische Schätzmethode

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Neben dem von Sven kürzlich vorgestellten Team Estimation Game, möchte ich heute noch eine weitere Herangehensweise vorstellen, die mir zu Ohren gekommen ist und eine zügige initiale Schätzung des gesamten Product Backlogs möglich machen soll: Magic Estimation.

Gerade beim Start eines neuen Projektes ist es häufig wichtig, schnell zu einer Aussage über den Zeitaufwand für die zu entwickelnden Funktionalitäten zu kommen. Vor dem ersten Sprint sollten daher ausreichend Backlog Items für mindestens 1-3 Sprints im Backlog vorhanden und priorisiert sein, um diese vom Team schätzen zu lassen. Keep Reading

Gastbeitrag: Die vierte Frage im Daily Scrum

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Im Rahmen des Daily Scrums werden von jedem Teammitglied in der Regel die folgenden drei Fragen beantwortet:

  • Was habe ich seit dem letzten Daily Scrum erreicht?
  • Was will ich bis zum nächsten Daily Scrum erreichen?
  • Was hindert mich im Moment daran, meine Arbeit zu machen?

Die ersten beiden Fragen sind sowohl für die Teamkollegen (Synchronisation) als auch für den ScrumMaster (Fortschritt? Tasks klein genug?) interessant, die dritte hauptsächlich für den ScrumMaster („Impediment! Are you ready to die?“).

Insbesondere bei eingespielten Teams, die sowieso sehr eng zusammenarbeiten, können die Daily Scrums sehr zügig über die Bühne gehen. Oft passiert es dabei, dass Impediments nicht mehr explizit benannt werden, sondern irgendwo im Grundrauschen verschwinden. So entsteht der Eindruck, dass alles prima läuft. Am Ende des Sprints kann dann das böse Erwachen kommen: Keep Reading

Gastbeitrag: Team Estimation Game

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Es wurde 2002 von James Grenning erstmalig beschrieben und später durch Mike Cohn’s Buch Agile Estimating and Planning sehr populär. Die Regeln sind sehr einfach und das Schätzen kann nach wenigen einführenden Worten starten. Die größte Schwierigkeit bei der Einführung liegt meines Erachtens darin, dem Team den Sinn einer Schätzung von relativer Komplexität anstelle von Aufwand in Arbeitsstunden zu vermitteln.

Wenn diese erste Hürde genommen ist, steht man vor der nächsten Herausforderung: Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument dient oft „Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen“. Wenn man diese Diskussionen als Scrum Master nicht in den Griff bekommt, dauert die initiale Schätzung des Product Backlog viel länger als geplant (falls man überhaupt durchkommt und die weitere Schätzung nicht in die Estimation Meetings während der Sprints verschiebt).

Auf dem Scrum Gathering 2009 habe ich nun eine Methode kennengelernt, die sehr vielversprechend klingt und schnell gute Ergebnisse liefert: Das Team Estimation Game nach Steve Bockman. Die Regeln für das Spiel sind simpel:

Keep Reading