Scrum Crash­kurs

Scrum Crashkurs Teaser
jetzt liken

Übersicht

  1. Scrum Kernpunkte
  2. Meetings
  3. Scrum / Kanban Board

Scrum Kernpunkte

Scrum ist eine Vorgehensweise beim planen und verteilen von Aufgaben an Mitarbeiter. Es hat klar definierte Regeln an die sich gehalten werden sollte. Zum einen bekommt jeder Mitarbeiter eine bestimme Rolle, Produkt Owner, Entwickler oder Scrum Master. Des weiteren gibt es fest definierte Meetings. Scrum selbst ist empirisch, inkrementell und iterativ, dies bedeutet, dass mit dieser Vorgehensweise eine unendliche Zeitspanne gearbeitet werden kann und nicht wie bei Wasserfall ein fixes Ende existiert.

Arbeitsprozess

Scrum 2 Wochen Sprint

Wenn das Projekt am Start steht muss zuerst der Backlog gefüllt werden, der Backlog ist ein Stapel an Aufgaben, der unsortiert, unbewertet und nicht priorisiert ist. Nachdem die ersten Aufgaben (Storys) definiert sind, kann aus dem Backlog ein priorisierte Aufgabenliste erstellt werden, diese nennt sich dann Sprintlog.

Scrum Ticket Informationen
Scrum Ticket Aufbau

Nachdem beide Stapel mit Aufgaben gefüllt sind, kann die erste Iteration starten. Wie auf dem Bild zu erkennen ist, wird bei Scrum die Aufgabe (Task) an einem Mitarbeiter verteilt. Bei Kanban dagegen, nimmt sich jeder Mitarbeiter Aufgaben selbst vom Stapel und bekommt sie nicht zugewiesen.

Rollen

Jeder Mitarbeiter bekommt eine Rolle zugewiesen, in dieser Rolle hat jeder seine bestimmten Aufgaben.

Product Owner

Der Product Owner ist der Leiter des Projekts, dieser definiert die Richtung des Sprints (die ab zuarbeiteten Tickets). Er steht in Verbindung mit den Stakeholdern, sprich Vorstand bzw. Geschäftsführung. Er berichtet den übergeordneten Leitern den Sprint/Produkt-Status, des weiteren muss der Product Owner die wirtschaftliche Effizienz messen und bewerten.

Scrum Master

Der Scrum Master ist eine Person die sich um den Ablauf im Scrum selbst kümmert. Er/Sie Master darf aber nicht die gleiche Person wie der Product Owner sein, da der Product Owner die Geschäftsführung vertritt und der Scrum Master das Team. Bei Problemen im Ablauf (zu geringe Storypunkte, Streit, Unklarheiten,…) muss der Scrum Master eingreifen, besser wäre es wenn diese Person die Probleme schon voraussehen kann und vorher schon einlenkt. Eine weitere Aufgabe ist es die Aufgaben bzw. Tickets an die Entwickler zu verteilen.

Entwickler

Der Entwickler bzw. Entwicklerin sind die ausführenden Kräfte. Dabei kann noch zwischen Konzept, Design und Entwicklung unterschieden werden. Die Entwickler erhalten Tickets vom Scrum Master und müssen während der Arbeit die abgeschlossenen Aufgaben im Ticket dokumentieren.

Storypoints

Storypoints definieren die Komplexität einer Aufgabe, die Komplexität wird meistens vom ganzen Team definiert. Dies nennt sich Planungspoker, jeder Mitarbeiter bekommt Karten mit Zahlen (1, 2, 3, 5, 8, …). Nachdem die Story vermittelt wurde, muss jeder im Team eine Karte hochhalten, danach wird der Mittelwert der hochgehaltenen Karten ermittelt und auf das Ticket geschrieben.
Nach dem Sprint wird ermittelt wie viele Punkte erreicht wurden um den nächsten Sprint besser planen zu können. Falls das Team regelmäßig zu viele Storypoints erhält die nicht abgearbeitet werden können, kann es passieren, dass Demotivation im Team entsteht. Des weiteren kann an den Storypunkten erkannt werden wie erfolgreich das Team ist bzw. ob es aktuell eine Steigerung oder Senkung der Effektivität entsteht.

Planig Poker

Meetings

Standup

Das Standup ist ein morgendliches Meeting, das nicht länger als 20 min. dauern sollte. Bei diesem Meeting treffen sich alle Teammitglieder und besprechen was am gestriegen Tag geschaft worden ist bzw. wo es Probleme gab. Danach gibt die Person noch die geplanten Aufgaben für den kommen Tag an. Während dieses Meetings wird auf der Tafel / Board die Aufgaben verschoben, damit alle Mitglieder auch den Arbeitsfluss mitbekommen.

Sprint Review

Nach dem zweiwöchigen Sprint wird dieser im Review präsentiert, dabei ist nicht nur das Team vertreten sondern auch die Stackholder, Anwender und Kunden. Dort wird der Fortschritt des Projekts bzw. Produkts erläutert und Meinungen von den Personen eingeholt, für die das Produkt gestaltet wird. In den meisten fällen tritt dabei der Produkt Owner als Moderator auf um sein Team dem Vorstand gut zu verkaufen, damit das Budget erhöht wird.

Sprint Retrospektive

In der Retro (umgangssprachlich) wird der abgeschlossene Sprint analysiert, dabei geht der Produkt Owner auf die Effektivität ein und prüft mit dem Team den Erfolg. Der Scrum Master hat bei diesem Meeting die Aufgabe Probleme und Unschönheiten im Team herauszufinden, als Beispiel könnten X Probleme gesammelt werden und danach geht jeder im Team mit ein oder zwei Sätzen auf das Problem ein. Des weiteren werden in diesem Meeting die Storypoints analysiert, ob das Team mehr oder weniger geschafft hat. Es ist empfehlenswert Kekse in dieses Meeting mitzubringen, damit jeder sich wohl fühlt und seine Scharm verliert und vielleicht auch Sachen anspricht die er/sie so nicht ansprechen würde.

Scrum / Kanban Board

Das Board ist für die Ticketübersicht des Teams gut. Auf dem Board kann man den Arbeitsfluss erkennen und nachschauen welche Aufgabe wem zugeteilt wurde. In den meisten Fällen wird ein Zweigleisiges System erstellt, dies bedeutet, es gibt ein physikalisches Board sowie ein digitales. Das Problem bei dieser Methode ist die Synchronisation zwischen den beiden Boards. Bei meinem Arbeitgeber hatten wir hauptsächlich am physikalischen Board gearbeitet und am digitalen die Dokumentationen hinterlegt.

Aufbau

Scrum Board

Das Bild ist an sich selbst sprechend, Backlog sowie Sprintlog ist weiter oben im Artikel schon detailreich erläutert. In der Development Spalte sind alle aktuell in Arbeit liegende Aufgaben. Tests steht in diesem Fall für die Qualitätssicherung und sobald diese Spalte abgearbeitet ist, kann das Ticket auf Done (abgeschlossen) geschoben werden.

Ticketbewegung

Tickets werden immer im Standup verschoben, damit alle Teammitglieder die aktuellen Aufgaben und Status der Aufgaben mitbekommen. Dies bringt Transparenz im Arbeitsablauf sowie eine Komprimierung der Arbeitszeit, da der Produkt Owner sowie der Scrum Master nicht unregelmäßige Termine diesbezüglich haben müssen.

jetzt liken