Oehen Kanzow & Partner

Scrum ist ein iteratives, inkrementelles Rahmenwerk für die Entwicklung beliebiger Produkte und dem Management beliebiger Arbeiten. Es erlaubt den Teams, je Iteration ein potentiell verkaufbares Set von Funktionalitäten zu liefern und bietet die Flexibilität, schnell und agil auf geänderte Anforderungen reagieren zu können.

Das Scrum Rahmenwerk hilft dem Team, sich auf kontinuierliche Verbesserung zu fokussieren. In Scrum wird davon ausgegangen, dass Änderungen in den Anforderungen auftreten werden. Im Rahmen der Sprints kann aber stabil an den immer wieder neu definierten Zielen gearbeitet werden.

Noch nie etwas von Scrum gehört? Dann sollten Sie hier weiter lesen!

Wenn eine Story so groß ist, dass sie erst nach mehreren Sprints abgenommen werden kann, lief etwas falsch: das Splitting der User Story. Es kann sein, dass die Story einfach zu groß ist, oder innerhalb des Sprints zuwenig Zeit für die Story bleibt, obwohl diese kleiner als der Sprint ist.

User Story nach Daten unterteilen

Wenn ein Formular für den Verkauf einer Immobilie erstellt werden muss, kann die Story bei den Daten Basisdaten, Preis & Finanzierung, Detailinformationen usw. unterteilt werden.

User Story nach Verarbeitungsart unterteilen

Die Daten für die Immobilie müssen zuerst gespeichert werden, dann können Sie gelesen, editiert und gelöscht werden. Dies nennt man CRUD Vorgänge. Create – Read – Update – Delete. Die User Story kann für diese Vorgänge aufgeteilt werden.

User Story nach Vertikal-Komponenten unterteilen

Sobald sich der Benutzer für das Erfassen einer Immobilie einloggen muss, fallen Vertikal-Komponenten zur Umsetzung an – Sicherheit, Logging, Errorhandling. Die User Story kann nun zweigeteilt werden, einmal ohne diese Komponenten, später mit diesen Komponenten.

User Story nach funktionalen und nichtfunktionalen Aspekten unterteilen

Wenn nun schon viele Immobilien erfasst wurden und eine Liste angezeigt werden soll, die alle Immobilien enthält, kann es sein, dass ein Caching-Mechanismus implementiert werden muss, damit die Liste schneller aufgebaut wird. Die User Story kann so unterteilt werden, dass der eine Teil die Präsentation der Liste enthält (funktional) und der andere Teil den Aufbau des Caching-Mechanismus enthält (nichtfunktional).

User Story nach Prioritäten unterteilen

Bei Verwalten der Immobilien sollen nun zuerst die Dinge umgesetzt werden, die einen hohen Business Value haben. So kann die User Story lauten „Als Benutzer will ich meine Immobilien verwalten können“. Darin findet sich nun beispielsweise die Story „Als Benutzer will ich Immobilien für den Verkauf aktiv setzen können“, dies hätte eine hohe Priorität, die Story „Als Benutzer will ich eine Liste meiner Immobilien exportieren“ hätte aber eine niedrige Priorität. Ein weiteres Beispiel kann sein, dass Validierungen, ob die Immobilie wirklich aktiv gesetzt werden darf (Validierung), in einem ersten Schritt weggelassen werden.

Vermeiden: User Story nach Einzelarbeitsschritte unterteilen

Auch wenn es manchmal nicht anders möglich aussieht, soll die Story „Als Benutzer will ich eine Immobilie erfassen können“ trotzdem nicht in die Arbeitsschritte „Formular erstellen“, „Zugriffsschicht erstellen“ und „Datenbank aufsetzen“ unterteilt werden. Es empfiehlt sich, einen Durchstich anzustreben, bei dem ein kleines Formular (wenige Felder) nur Erstellend (das C aus CRUD) ohne Validierung eine Immobilie auf die Datenbank (ohne Überprüfung der Datenintegrität) schreibt.

Vermeiden: der nun kleinen User Story mehr Arbeit hinzufügen

Wenn die Story nun implementiert wird, könnte doch noch schnell dies und das links und rechts erledigt werden – nein! Der Story soll nichts hinzugefügt werden. Ausnahme: die Änderungen müssen mindestens die gleiche Priorität wie die aktuelle Story haben, dann können diese unter Berücksichtigung des Zeitplanes umgesetzt werden.

Es ist nun aber nicht die Meinung, dass die Stories so klein wie möglich gemacht werden sollen. Eine gute Größe für Stories ist 2 – 5 Tage – dies hält den Fluss der Arbeit aufrecht.

Es bietet sich an, User Stories nicht nur zu unterteilen, sondern diese auch, wenn sie zu klein sind, zu kombinieren. So können zum Beispiel Bugs zu einer Story zusammengefasst werden. Es wird dann auch diese kombinierte Story geschätzt und nicht jeder Bug einzeln.

Chicken to Pig: Let’s open up a restaurant and name it Ham and Eggs. Pig to Chicken: I’d rather not as I will be committed, and you just involved (SCRUM wisdom)

Ein Huhn und ein Schwein machen sich Gedanken über die Zukunft…

• Huhn: Lass uns ein Restaurant eröffnen!
• Schwein: Und wie sollen wir es nennen?
• Huhn: „Schinken und Ei“!
• Schwein: Nein danke. Da wäre ich verpflichtet, Du aber nur beteiligt!

Auf Scrum übertragen: das Team, der Scrum Master sowie der Product Owner sind dem Projekt verpflichtet (also Pigs), d.h. sie sind direkt am Projekt beteiligt und tragen das Risiko.

Die anderen Interessensgruppen (also Chickens) sind zwar am Projekt interessiert, sind aber höchstens Zuhörer und nur selten bei den Meetings dabei und tragen kein Risiko.

That’s all!

Mir fällt bei der Einführung von Scrum auf, dass nicht unbedingt der Prozess schwierig zu erlernen ist, sondern die Dinge rund ums Team, Zusammenarbeit und Spezifikation.

Spezifikation

Nur weil wir Scrum machen, fällt diese nicht komplett unter den Tisch. Natürlich wird kein 1000 seitiges Dokument mehr geschrieben, dafür hat die Liste, in die die Stories eingegeben werden, durchaus 1000 Zeilen! Die große Kunst nun ist es, diese Stories so zu schreiben, so zu unterteilen, dass die Entwickler verstehen, was sie zu tun haben und die wichtigsten Dinge zuerst erledigt werden.

Was sind wichtige Eckpunkte einer Story:

• Indpendent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

= INVEST!

Zusammenarbeit

Vertauen muss da sein. Das Team muss dem PO vertrauen, dass er den richtigen Hafen ansteuert, während der PO dem Team vertrauen muss, das es die richtige Technik vorgibt, um den Hafen sicher zu erreichen. Zudem müssen Entscheidungen gefällt werden. Welche Story soll wie hoch priorisiert werden, ist diese technische Anforderung (die vom Team kommt) wirklich wichtig, wenn ja, wird sie in den Sprint aufgenommen? Stimmt die Architektur, sind die Entscheidungen, die bei einer späten Änderung hohe Kosten verursachen, schon früh im Projekt gefällt worden? Wird hier nach dem Prinzip KISS (Keep it small and simple) vorgegangen, oder wird bewusst eine etwas ausführlichere Variante gewählt? Und wer hält dafür den Kopf hin?

Team

Bei Scrum kommt immer wieder das Thema “Selbstorganisation” ins Spiel. Sind wir ehrlich: ein Team, das neu Scrum macht, hat keine Ahnung, was damit gemeint ist. Das Daily Scrum findet nicht statt, weil der Scrum Master heute krank ist – hmmmm? Ist das Daily Scrum für den Scrum Master oder für das sich jeden Tag aufs neue organisierende Team? Klar, fürs Team. Das Team muss auch ein Standing entwickeln, sich hinzustellen vermögen, wenn Anforderungen unklar sind. Das Team muss, wenn der Scrum Master es nicht davor schützt, selbst schreien, wenn ein Commitment von ihm verlangt wird, das es nicht einhalten kann (z.B. werden Schätzungen extern gemacht und das Scrum Team muss sich dazu commiten – hier muss der Scrum Master das Team schützen).

Wenn diese drei Dinge erledigt sind, wird es im Scrum bereits schon viel runder zu und her gehen, das Projekt nimmt Fahrt auf.

Der Kunde, der bereits Scrum im Einsatz hatte, aber sich ein externen Scrum Coaching einkaufen wollte, hat mich bei unserem Erstgespräch gefragt, was ich denn als Scrum Coach den ganzen Tag zu tun gedenke?

Nun, die Frage ist berechtigt, zumal der Scrum Coach nicht “direkt” Mehrwert schafft. Das heisst, er schreibt keinen Code, und keine Dokumentation. Der Mehrwert eines Coaching ist eher langfristig und indirekt ersichtlich.

Je nachdem, in welcher Stufe sich der Scrum Prozess bei der Firma befindet, gehe ich nach den Schritten “Einführung – Anwenden – Überprüfen – Anpassen” vor.

Einführung

• Scrum vorstellen, dem Team aber auch dem Management
• die Personen in den Rollen, die sie wahrnehmen, schulen
• zusammen mit dem Product Owner und dem ScrumMaster das Product Backlog erarbeiten, für den ersten Sprint
• mit dem Team die ersten Schätzungen des P/B durchführen
• zusammen mit dem Scrum Master das Task Board vorbereiten
• …

Anwenden

• den ersten Sprint durchführen
• die Meetings zusammen mit Scrum Master vorbereiten
• Meetings durchführen
• Entwicklungs-Prozess beobachten und in Workshops Verbesserungen erarbeiten
• den Scrum Master die Impediments beseitigen lassen
• …

Überprüfen

• mithilfe des Retro-Meetings den Scrum-Prozess überprüfen
• einzeln mit dem Team, dem PO und dem SM den Prozess kritisch durchleuchten
• Menschlich, fachliche und technische Hindernisse erkennen und Veränderungen einleiten
• …

Anpassen

• nicht den Scrum-Prozess anpassen, sondern die Voraussetzungen im Unternehmen schaffen oder wiederherstellen
• mit den Ansätzen des Lean Managements arbeiten, um Verschwendungen zu erkennen
• …

Als Coach trinke ich natürlich auch gerne mal einen Kaffee, aber hauptsächlich bin ich mit einem offenen Ohr beim Team, dem Product Owner und dem ScrumMaster unterwegs – um die Hand reichen zu können, wenn jemand nicht weiterkommt.

Wahrscheinlich kennen Sie die Herausforderung, von einer Grobidee zu einem Product Backlog zu kommen. Nun, wie könnte ein systematisches Vorgehen aussehen?

Ich empfehle, mit der Produktvision zu beginnen. In den Dimensionen Zeit / Kosten / Visionserfüllung muss die Balance gefunden werden, mit dem Ziel, das bestmögliche Produkt zu erstellen.

Kerneigenschaften der Produktvision

• sie ist akzeptiert, gemeinsam erarbeitet
• sie ist stabil und klar formuliert
• sie ist motivierend und breit formuliert (Freiraum lassend)
• sie ist kurz und bündig

Die Produktvision soll stabil sein, das Product Backlog jedoch ist dynamisch. Was heisst das? Das heisst, die Vision soll über mehrere Sprints stabil sein, und je nach Anforderung alle 3 oder 6 Monate angepasst werden. So kann während der Sprints auf die Vision hingearbeitet werden (es werden nur Dinge abgearbeitet, die der Vision dienen!). Das P/B jedoch kann sich vor / während / nach dem Sprint ändern, ist eben dynamisch (Priorisierung und Schätzungen anpassen, Stories rein / raus etc.).

Output der Produktvision

• Wer ist der Kunde, wer ist der Benutzer?
• Welche Bedürfnisse werden durch das Produkt befriedigt?
• 10 kritische Produkteigenschaften?
• Stellung zu bestehenden Produkten
• Zeit- und Kostenrahmen
• Geschäftsmodell
• Stückpreis und -kosten

Wenn ich mir obige Punkte ansehe, könnte ich mir vorstellen, diesen Output auf eine Kartonschachtel zu drucken und diese Schachtel mit dem Produkt drin in die Software Abteilung des Kaufhauses am Ort zu tragen – vielleicht fühlt sich ein Kunde davon angesprochen?

Zum Unterschied Kunde / Benutzer: in einem größeren Unternehmen wäre die Abteilung, die die Software einkauft und installiert der Kunde, jedoch ist der Endanwender an dem einzelnen PC der Benutzer. So ist es dem Benutzer egal, ob die Software-Einstellungen zentral verwaltet werden können (Hauptsache „es läuft“), während dieses Feature dem Kunden durchaus wichtig sein kann.

Wie viel Zeit wird in die Erstellung der Produktvision investiert? Gerade genug Zeit, um obige Punkte zu erhalten. Auch bei der Produktvision gilt: sie kann nicht im Vorfeld endgültig erstellt werden, sie wird sich dynamisch verändern, dies aber im 3 oder 6 Monate Rhythmus. Es lohnt sich also nicht, ein Big Upfront Planning zu machen (wie immer bei Scrum ).

Und nun, um dem Titel des Beitrags gerecht zu werden, wie kommen wir von der Produktvision zum Product Backlog? Indem wir die 10 kritischen Produkteigenschaften nehmen und als Stories in das Product Backlog schreiben. Wenn der Detaillierungsgrad noch nicht passt, wird die höchstpriore Story einfach in 3-5 weitere Stories runter gebrochen und diese neuen Stories auch gleich priorisiert. Nun gehen Sie so weiter vor, bis Sie max. 100 Stories in Ihrem initialen Product Backlog haben. Das sollte eigentlich klappen!

Produktplanungsstrategie

• das Produkt soll einfach gehalten werden, also keine Eierlegende Wollmilchsau sein → „Small is beautiful“. Lieber schnell an den Markt und damit früh ein Feedback vom Markt einholen.
• mit Versionen arbeiten, inkrementelle Auslieferung
• fester Innovationsrhytmus (Zeit ist Time-boxed), z.B. alle 3 Monate eine neue Version veröffentlichen

Ich hoffe, Sie als Product Owner mit diesen Informationen ein wenig näher zum idealen Produkt gebracht zu haben