Scrum for One - Scrum alleine einsetzen Teil 3

Wie kann man Scrum auch alleine einsetzen?
Hier möchte ich meinen Weg aufzeigen. Mit den Scrum Mittel kann sich jeder sein eigenes System erstellen.

Startphase

Der Auftraggeber hat eine Idee von einem Produkt. Zuerst wird das Gesamtbild, das Endprodukt besprochen. Ich lasse mir als die Vision erklären.

Sollte der Auftraggeber keine Userstories haben. Lege ich für das Projekt welche an. Wir besprechen die Userstories. So kann der Auftraggeber nochmal prüfen, ob sein Produktwunsch verstanden wurde.

Release-Planung

Wenn die Userstories besprochen sind, ordnet der ProduktOwner (Auftraggeber) diese in eine Reihenfolge. Ich erstelle dann ein Produkt-Roadmap. Dazu reicht oft ein DIN A4 oder A3 Blatt aus. Diese ist immer präsent aufgehängt oder liegt am Arbeitsplatz. Damit kann man gut den Focus auf das Projektziel halten. Das verhindert auch mehr Arbeit, die nicht bestellt wurde.

Schätzung der Userstories

Nach der Schätzung der Userstories kann ich die eigentliche Arbeit beginne. Bevorzugt in einem 1-Wochensprint oder 2 Wochen Sprint. Da in diesen kurzen Abständen, das Feedback schneller eingebunden werden kann. Besonders dann wichtig, wenn der Kunde selbst nur eine vage Vorstellung vom End-Produkt hat.

Sprint vorbereiten

Die Userstories werden in der Reihenfolge abgearbeitet. Für die Tasks nehmen ich DIN A4 Blätter. Jede Userstory hat sein eigenes Blatt. Das Blatt liegt beim Arbeiten im Querformat vor der Tastatur und erlaubt mir immer einen schnellen Einblick. Die Userstory kommt als Überschrift als Stichpunkt auf das Blatt oben. Wenn ich an mehreren Projekten arbeite, schreibe ich meist auch ein Kürzel für das Projekt mit dazu. So kann man gut die Task-Blätter organisieren. Auf ein ScrumBoard verzichte ich damit. Vor mir liegt die Produkt-Roadmap und die Blätter mit den Userstories. 

Die Userstories stappel ich. Damit bleibt der Focus auf das aktuelle Abarbeitungspaket. Auf jedem Blatt erfasse ich die nötigen Schritte für die Umsetzung. Das sind die Tasks. Wenn die Reihenfolge im Laufe der Entwicklung geändert wird, schreibe ich mir Zahlen an die Tasks. Wenn es zu unübersichtlich wird, schreibe ich das Blatt einfach neu. 

Durch das Erfassen der Tasks gehe ich den Entwicklungsprozess der Userstory im Kopf durch. Dabei fallen mir Arbeitsschritte ein, die ich vorher vergessen habe zu berücksichtigen. Im Laufe der Entwicklung kommen auch immer wieder Tasks dazu oder manche werden entfernt. Das Entfernen demonstriere ich durch das Durchstreichen mit wellenartige Linien. So kann ich abgearbeitete Tasks von verworfenen gut trennen.

Zeitschätzung jederzeit möglich

Da sich die Tasks bei mir tatsächlich immer im gleichen Zeitbereich bewegen, kann ich auch schnell eine Aussage über die Dauer geben. Somit kann ich die eigentliche Schätzung gut anpassen. Ich zähle einfach die Tasks und multipliziere diese mit meiner durchschnittlichen Zeit pro Task.

Sprint machen

Wenn die Tasks stehen, geht es los. Ich arbeite die Tasks der Reihe nach ab. Daten und Informationen die ich benötige und mir im Laufe der Entwicklung einfallen, werden direkt auf das Blatt geschrieben. So bleibt alles zusammen.

Jeder erledigte Task wird durchgestrichen. Das gibt eine gutes Gefühl und motiviert gleich zu weiteren Arbeiten. Die Tasks selbst sind in der Regel auch kurz und klein gehalten. Die umgesetzten Tasks werden wenn möglich sofort in ein Quellcode-Versionierungssystem eingecheckt. Damit bleiben die Änderungen erhalten und man kann schnell wieder den alten Zustand herstellen.

Daily Scrum

Ist nicht wirklich nötig. Da ich alleine an dem Projekt arbeite. Aber für den Beginn der Entwicklung sichte ich meist nochmal die erledigten Tasks und reflektiere nochmals was zu tun ist. Auch ein Blick auf die Gesamtstory ist sehr vorteilhaft, also die Roadmap ansehen.

Sprint Review

Das Sprint Review mache ich mit dem Kunden entweder gemeinsam, Live per Skype oder er sendet mir seine Anmerkungen per Email zu. Das Inkrement stelle ich dafür auf meinen Testserver und sende ihm den Link zu. Rework kommt in die nächste Sprintplanung. Damit kann ich dann auch Verlängerungen in der Projektdauer gleich kommunizieren.

Sprint Retrospektive

Ist etwas schwierig alleine. Da kann helfen, den Kunden zu fragen, ob er noch eine andere oder verbesserte Kommunikation wünscht. Für mich versuche ich schon während der Entwicklung, Optimierungen gleicht anzuwenden. Motto: Man lernt nie aus. Dafür lese ich mich immer wieder in Bücher für besseres Programmieren und Testen ein.

Fazit

ScrumForOne geht. Man muss etwas disziplinierter sein, aber kann schnell gute Erfolge erzielen. Viel Spass mit diesen Anregungen.

Scrum for One - Scrum alleine einsetzen Teil 2

Definition of Done

Sie erhält Einschränkungen und Anforderungen die vom ganzen Team als globale Qualitätskriterien angesehen werden. Jeder Backlog-Eintrag kann zusätzliche Anforderungen für die Abnahme erhalten. Im Laufe der Entwicklung fordert das Scrum Team immer mehr Kriterien für die Qualität von sich selbst. Diese werden dann in die "Definition of Done" eingetragen.

Die "Definition of Done" (DoD) wird gut sichtbar aufgehängt und ist dem Scrum Team bekannt. Die DoD wird zwischen dem  ProductOwner und dem Entwicklungsteam ausgemacht. Nur Backlog-Einträge die alle DoD Akzeptanzkriterien erfüllen, werden als "fertig" betrachtet.

Daily Scrum

Damit bringt sich das Entwicklungsteam auf den neuesten Stand. Diese Meetings sind sehr kurz und werden täglich, bzw jeden Entwicklungstag abgehalten. Jedes Team-Mitglied beantwortet drei Fragen:

• Was habe ich seit der letzten Besprechung erreicht?
• Was wird bis zur nächsten Besprechung erledigt?
• Welche Hindernisse stehen im Weg?

Die Beantwortung geht reihum und jeder sollte sich kurz halten. Maximal 1 Minute pro Person. Weitere Gespräche werden nur mit den betroffenen Personen im Anschluss des Meetings gesondert geklärt. Um es für alle einfach zu machen, sollten die Meetings immer am gleichen Ort zur gleichen Zeit stattfinden. Nur das Scrum Entwicklungsteam darf sprechen. Der Scrum Master moderiert.

Anschließend werden Aktualisierungen gemacht am:

• Sprint Backlog
• Sprint Burndown
• Impediment Backlog (Hindernisse)

Das Impediment Backlog wird vom Scrum Master abgearbeitet.

Sprint Burndown

Dieser Chart zeigt den Fortschritt des aktuellen Sprints. Auf der vertikalen Achse wird die verbleibende Arbeit eingetragen. Auf der horizontalen stehen die Arbeitstage. Das Einzeichnen erfolgt im Daily Scrum.

Inkrement

Das Inkrement stellt den aktuellen Zustand eines Programmes dar. Alle Ergebnisse aus den erledigten Sprints sind enthalten. Nach jedem Sprint entsteht ein neues Inkrement. Das Inkrement muss funktionieren, bzw. benutzbar sein. Die Qualität entspricht immer der "Definition of Done"

Sprint Review

Hier wird das neue Inkrement abgenommen. Das Sprint Review wird am Ende eines Sprints gemacht. Das Entwicklungsteam führt das Inkrement vor. Der Fokus der Produktvorführung liegt auf den Sprintzielen. Die Präsentation erfolgt nur für tatsächliche Ergebnisse. Keine "ist eigentlich fertig" oder Bilder und Folien. Die Stakeholder und das Scrum Team besprechen die Ergebnisse und beschliessen den Nächsten Schritt.

Sprint Retrospektive

Im Anschluss an das Sprint Review analysiert das Scrum Team den abgearbeiteten Sprint. Verbesserungsvorschläge für das Arbeiten werden ermittelt und für die folgenden Sprint festgehalten.

Grooming

Vor dem Start der Planung des nächsten Sprints wird das Product Backlog durch den Product Owner auf den neuesten Stand gebracht. Änderungen und Reihenfolgenanpassungen werden erläutert. Das ganze Team erfährt die neuen Anforderungen. Das Entwicklungsteam muss die neuen UserStories schätzen. Auswirkungen auf das weitere Vorgehen und eventuell neue Anforderungen an "Definition of Done" werden erörtert.

Release Burndown

Der Product Owner ist für das End-Produkt verantwortlich. Er bestimmt die tatsächlichen Features und den Umfang des Produkts. Die Product Backlog-Einträge kann er in einen Release Plan eintragen. Wenn die UserStories geschätzt sind und die in der Regel gleichbleibende Anzahl an Storypoints abgearbeitet werden, dann kann der Product Owner einen Releaseplan erstellen. Die kompletten Storypoints werden in Sprints umgerechnet. Die Sprints werden gezählt.

Ähnlich wie der Sprint Burndown wird auch der Release Burndown erstellt. Vor jedem Sprint trägt der Product Owner die zu erreichenden Storypoints ein.  Auf der vertikalen Achse steht die verbleibenden Arbeit für das Release. Auf der horizontalen Achse stehen die Sprints. Damit kann die Abarbeitungsgeschwindigkeit ermittelt werden. Je mehr Sprints gemacht wurden, desto genauer wird die Zeitplanung.

Im Teil 3 folgt:

Umsetzung von Scrum mit nur einer Person

Scrum for One - Scrum alleine einsetzen Teil 1

Scrum ist eine sehr gute Sache. Ideal für Teams ab 3 Personen. Was machen Freelancer und Entwickler die für sich selbst arbeiten?

ScrumForOne nenne ich die Scrum-Prinzipien auf eine Person umgewandelt. Dabei kann man die Zyklen eines Scrum-Ablaufs auch alleine machen. In meinen nächsten Posts beschreiben ich die einzelnen Teile und wie man Scrum auch alleine machen kann.

Scrum Zyklen

Am Anfang ist der Projektauftrag. Der Produkt-Owner formuliert diesen mittels Userstories. Die Sortierten Userstories stellen das Produkt Backlog dar. Pro Iteration werden einige Einträge aus dem Produkt Backlog in einem Sprint abgearbeitet. Der Sprint hat eine fest Dauer von 2-4 Wochen. Nach dem Sprint wird das erstellte Werk begutachtet und die Planung für den nächsten Sprint kann beginnen. 

Vor der Planung wird die Retrospektive gemacht. Das Team reflektiert den vergangenen Sprint und seine eigene Arbeitsweise. Was war gut, was war weniger gut, was machen wir nun damit wir uns verbessern?

Die weiteren Zwischenschritte und die Umsetzung, wenn man ScrumForOne macht folgen in den nächsten Beiträgen.

Scrum Team besteht aus mehreren Rollen

Product Owner (Produktbesteller, der entscheidet was das Produkt demnächst braucht)

Scrum Master (Moderator und Coach für das Vorgehen im Scrum)

Scrum Team (die Umsetzer)

Alle Scrum Rollen in Einer

In der Regel sollte keine Rolle mit der gleichen Person mehrfach belegt sein. Bei ScrumForOne ist das genau umgekehrt. In der Regel sind alle Rollen mit dem Freelancer besetzt. Idealerweise hat setzt der Freelancer Kundenanfragen um, dann ist er ProductOwner der Auftraggeber. Bei eigenen Projekten ist man alles.

Ohne Disziplin geht Scrum nicht

Diese Art der Umsetzung von Scrum erfordert etwas Disziplin. Man muss sich einen Plan erstellen. Man muss sich an den Plan halten. Man muss so sich selbst reflektieren und verbessern. Ja, man muss sich selbst verbessern wollen.

Anforderungen einsammeln bevor Scrum beginnt

Egal ob im Team oder nicht, man braucht einen Plan. Schreiben Sie die Anforderungen an die Software als Userstories. Bringen Sie die Userstories in eine Reihenfolge. Versuchen Sie die Userstories unabhängig voneinander zu gestalten. Userstories sollten nicht von anderen Userstories abhängig sein. Setzen Sie die wichtigsten Userstories an den Anfang. Die wichtigsten Userstories sind diejenigen, welche das Produkt in der einfachsten Version benötigt und Ihnen eine erste Veröffentlichung ermöglichen könnte.

Wie erstellt man Userstories?

Jede Userstory enthält eine Anforderung mit Nennung des Grundes und von wem diese Anforderung stammt. Der Aufbau folgt:

• Wer möchte welches Feature, damit Was erreicht wird
• Als Nutzer will ich Ziel/Wunsch damit Nutzen entsteht

Beispiele:

• Als User benötige ich eine Kontoübersicht, damit ich meinen Kontostand einsehen kann
• Als Administrator benötige ich eine Liste mit geblockten Accounts, um schneller einen Überlick zu erhalten
• Der Service benötigt eine Backup-Option, um Datensicherungen von Kunden erstellen zu können

Halten Sie den Aufbau kurz und präzise. Man kann die Userstories schrittweise verfeinern und in detailiertere Userstories aufsplitten.

Die Userstory erklärt auch den Grund für das Bedürfnis.

Damit kann der Entwickler besser verstehen, was mit diesem Feature erreicht werden soll. So ist er in der Lage die erwartete Funktionalität optimaler umzusetzen. Es entstehen weniger Missverständnisse.

Product Backlog von Scrum

Alle Elemente in Form von Userstories stellen das Product Backlog dar. Diese Elemente sind nach Wichtigkeit für den Product Owner sortiert. Sie beschreiben das ganze Produkt. Anpassungen an der Reihenfolge wird durch den Product Owner immer wieder vorgenommen. Wenn neue Anforderungen entstehen oder gar wegfallen, wird das Product Backlog durch den Product Owner angepasst.

Product RoadMap bietet Übersicht des kompletten Produkts

Die Product RoadMap enthält das Product Backlog. Die Backlog Einträge werden hier in Pakete gepackt. Diese Packet entsprechen den Versionen des Products. Jedes Packet kann in mehrere Bereiche unterteilt werden. In diese Bereiche kommen die Product Backlog Einträge. Damit kann man schnell erkennen, was das Produkt wann können wird. Dabei zeichnet man am Besten eine Kreuztabelle.

Beispiel:

	Nutzerverwaltung	Verkauf	...
Skeleton	Kunden erstellen, Löschen, Bearbeiten Kunden listen		...
Version 1	Kunden sperren	Newsletter erfassen Newsletter versenden Shop verlinken, Affiliate tracken	...
...

Scrum Sprint

Die Dauer für einen Sprint wird für das Projekt komplett festgelegt. Sollte zwischen 2 und 4 Wochen sein. In einem Sprint werden Backlog Einträge umgesetzt. Am Ende des Sprints werden die Ergebnisse übergeben.

Das Sprint beginnt mit einer Sprint Planung 1 und Sprint Planung 2. Anschließend werden die abgeleiteten Task aus dem Sprintziel umgesetzt. Jeden Tag wird ein Daily Scrum durchgeführt. Dabei werden die geschafften Tasks erwähnt und die nächsten Tasks genannt. Probleme werden ebenfalls in den Problemspeicher notiert. Der Problemspeicher enthält Störungen und andere Probleme, die beseitigt werden müssen, damit die Umsetzung nicht gestört wird.

Wenn der Sprint fertig ist, werden die erstellten Teile präsentiert. Nicht erstellte Teile oder unfertige Tasks und Produckt Backlog Einträge werden nicht präsentiert. Diese wandern wieder in den Produkt Backlog und werden in der Sprint Planung 1 vom Produkt Owner neu priorisiert.

Scrum Sprint Planung 1

Der ProduktOwner stellt seine Produkt Backlog.Einträge vor. Hier wird die gesamte Produktvision und Story nochmal als Ganzes gesehen. Wenn es Änderungen an den Einträgen gab oder diese umsortiert wurden, wird hier nochmal besprochen ob es Auswirkungen auf das gesamte Produkt gibt.

Die Abhängigkeiten und das eigentliche Produktziel soll im Hinterkopf behalten werden, damit während der Entwicklung entsprechend programmiert wird. Mit diesem Hintergrundwissen kann man leichter Entscheidungen für eine bestimmte Variante oder Vorgehensweise treffen.

Nun werden die umzusetzenden Einträge festgelegt. Dabei werden in Abhängigkeit von der Sprintdauer, die Produkt Backlog-Einträge als Sprintziel definiert. Diese müssen in ein Sprint realisiert werden und ergeben das Sprint Backlog.

Scrum Sprint Backlog

Das Sprint Backlog besteht aus den Produkt Backlog Einträgen, die der Produkt Owner umgesetzt haben möchte und die Entwicklung realistisch in der Zeit eines Sprints umsetzen kann. Die Bewertung der Dauer pro Backlog Eintrag wird durch die Entwickler geschätzt. Bei ScrumForOne sollte man sich bewusst die Einträge ansehen und nur nach der Schätzung auswählen. Nicht nach dem eigenen Wunsch was man alles realisieren will. Das sollte über die Priorisierung geklärt werden.

Scrum Sprint Ziel

Beschreibt was am Ende des Sprints realisiert werden soll. Dabei ist es das Ziel alle Sprint Backlog-Einträge umzusetzen. Das Sprint Ziel kann aber nochmal als Satz formuliert werden. Was wird in dieser Iteration erreicht? Das hilft den Focus zu behalten und kann auch für die Aussenkommunikation genutzt werden. Beispiel: Wir arbeiten gerade an der Realisierung der Bestellabwicklung.

Scrum Sprint Planung 2

Die Einträge aus dem Sprint Backlog werden in kleinere Tasks umgeschrieben und entsprechend in der Umsetzungsreihenfolge erfasst. Durch diese Übersicht, verliert man das Ziel nicht aus den Augen und verhindert, dass man sich in kleine Aufgaben verzettelt. Auch werden so nicht immer wieder neue Baustellen begonnen. Die Vorbereitung der umzusetzenden Aufgaben ist sehr wichtig.

Im Teil 2 folgt:

Definition of Done
Daily Scrum
Sprint Burndown
Inkrement
Sprint Review
Sprint Retrospektive
Grooming
Release Burndown