Heute schauen wir uns mal genauer an, was den Kern einer jeden agilen Umsetzung ausmacht. Daher steht im Rampenlicht: Die „Story Card“. Auch wenn das erstmal nur nach einem weiteren Buzz-Word klingt, ist ihre Bedeutung tatsächlich immens. Wir erklären, was Story Cards sind und wie sie aufgebaut sein sollten, damit eine Umsetzung schnell und reibungslos auch in kleinen Teams erfolgen kann. In erster Linie ist das also für Product Owner wichtig, denn die sind primär dafür zuständig.
Weiterlesen
Wir werden uns auf die wesentlichen Faktoren konzentrieren, die für Euch als Team relevant sind. Mit dem genauen Bearbeitungszyklus verschonen wir Euch, keine Sorge. Wir werden aber aufzeigen, worauf Productowner achten sollten, bevor ihre Themen in die Umsetzung gehen. Denn so eine Story bedarf besonderer Vorbereitungen, damit die Umsetzung möglichst reibungslos funktioniert, um das gewünschte Ergebnis zu erhalten.
Holen wir also eben tief Luft. Üblicherweise wird in einem Sprint- oder Kanban-Backlog eine neue Funktion in Form einer Userstory beschrieben. Der User ist nämlich immer im Fokus. Für die soll das System einen neuen Mehrwert bieten. Weitere Details zur Userstory etwas später.
Wir benötigen zunächst ein großes Board – am besten an einer Wand hängend, damit alle Stakeholder und Teams alles im Blick haben können. Zudem benötigen wir Kärtchen, auf die wir jeweils eine Story schreiben (Plot-Twist: Die Kärtchen kommen anschließend aufs Board). Da sich, Pandemie-bedingt, in den letzten Jahren irgendwie alles verändert hat, lässt sich so ein Board, dank Home Office, natürlich auch sehr bequem virtuell umsetzen. Jira, Trello, Asana und Co. sind hierbei praktische Helfer. Die eigentlichen Besprechungen selbst finden per Videokonferenz statt.
Die Story Cards
Wichtig: Auf jeder Story Card sollten alle Interessierten (!), also auch Personen, die nicht vom Fach sind, alles verstehen können. Dazu gehört, welcher User (Rolle) was genau machen kann und warum. Zudem enthalten sie eine aktuelle Einordnung, wie wichtig sie aktuell sind, also wie hoch der Mehrwert – aktuell – ist im Verhältnis zu den anderen Stories. Diese Einschätzung kann sich im Laufe der Zeit natürlich auch noch ändern, muss also immer wieder upgedatet werden. Und damit sich alle Beteiligten auch einigen, ab wann eine solche Story auch wirklich vollständig realisiert wurde (hier gibt es in der Praxis häufig Ärger und Missverständnisse), werden hier auch Informationen hinterlegt, was alles als Abnahmekriterium gelten soll.
Diese Infos sollten nicht arg fachlich, bzw. technisch sein, damit wirklich alle genau verstehen, was Sache ist. Ist das noch nicht der Fall, muss das noch geklärt und Formulierungen angepasst werden.
So, wird Zeit die Ärmel hochzukrempeln und richtig in die Details einzusteigen!
Teil 1: Die Userstory
Der User und die Userstory stehen immer im Vordergrund. Hier werden keine Funktionen beschrieben, oder wie sie genau aussehen sollen („roter Rahmen“). Ausschlaggebend ist immer die User-Sicht (Mitarbeiter und Mitarbeiterinnen können in bestimmten Szenarien natürlich ebenfalls User sein). Die Userstory erklärt, weshalb diese Funktionalität wertvoll ist.
Diese Userstory sollte nach dem sogenannten INVEST-Kriterium formuliert sein und folgt immer diesem Schema:
„Als [Rolle] möchte ich [Funktion], um [Nutzen].“
Heruntergebrochen ergibt das beinahe den Klassiker aus der Sesamstraße: Wer, was und warum? (Ohrwurm inklusive – gern geschehen!)
INVEST-Kriterium? Was ist das?
Der Fragesatz selbst sollte folgende Punkte erfüllen:
- Independent (unabhängig): Keine Abhängigkeiten von anderen Stories
- Negotiable (verhandelbar): Alle Beteiligten diskutieren und präzisieren gemeinsam, um gutes Verständnis zu erlangen
- Valuable (wertvoll): Die Story muss einen klaren Nutzen eines Stakeholders aufzeigen
- Estimable (schätzbar): Wie viel Aufwand bedeutet die Story?
- Small (klein): In einem Sprint realisierbar
- Testable (testbar): Am Ende sollten alle angedachten Eventualitäten auch getestet werden können
Teil 2: Abnahmekriterien
Im nächsten Schritt sollten alle sogenannten Akzeptanzkriterien formuliert werden: Wann sind alle Kriterien an die Story erfüllt, sodass sie fertig realisiert ist? Hier sollte es zu keinen Missverständnissen kommen können. Daher ist es wichtig, dass diese Kriterien für alle Beteiligten eindeutig formuliert werden. Am Ende gibt es sonst nämlich nur Verwirrung.
Oft setzen Abnahmekriterien auch bestimmte Zustände voraus. So fangen Akzeptanzkriterien oft so an, wie an diesem Beispiel zu sehen ist: „Angenommen, der <User-Rolle> existiert noch nicht im System, und das System enthält die Datensätze zu XY….“
Ebenfalls wichtig ist auch, dass alle (!) Abnahmekriterien bedacht und auch formuliert werden. Werden später Mängel entdeckt, bspw. durch eine andere Kombination von Eingaben oder weil das System einen anderen Ursprungszustand hatte, gilt die Story dennoch als erfolgreich umgesetzt. Eine Anpassung (für die Stakeholder ist es eine Fehlerverbesserung) ist dann nur noch mit einem komplett neuen Vorgang möglich.
Kleiner Tipp: Ein einziges Abnahmekriterium kann niemals vollständig sein. Folgende Fragen helfen hier weiter:
- Gibt es Situationen, bei denen das System sich anders verhalten soll?
- Was ist, wenn Eingaben fehlen oder falsch sind?
- Was ist, wenn andere Grundannahmen herrschen, bspw. wenn bestimmte Informationen in der Datenbank fehlen, eine Datei fehlt oder die hinterlegte E-Mail-Adresse ist falsch?
- Was ist, wenn ein benötigtes Teilsystem (kann auch ein externer Anbieter sein) nicht erreichbar ist?
Gleichzeitig dürfen wir nicht vergessen, dass wir die benötigten Testdaten, Voraussetzungen und Zustände der Teilsysteme für jedes dieser Szenarien formulieren, damit das auch wirklich so abgenommen werden kann. Und diese Daten und Zustände beim Umsetzungsstart von jemanden auch alles anlegen zu lassen.
Ihr merkt schon, dieser Punkt erfordert etwas mehr Aufmerksamkeit und Zeit. Nehmt Euch also bitte die Zeit, Euch in alle Situationen reinzudenken und alle Eventualitäten abzufrühstücken.
Teil 3: Die Angabe des Mehrwerts
Stories müssen für alle Beteiligten miteinander vergleichbar sein, um sie richtig priorisieren zu können: Welche Stories ergeben aktuell den meisten Mehrwert? Welche den zweitmeisten? …
Wie Ihr priorisiert, ist Euch überlassen. Häufig sieht man zwei Ansätze: Ihr könnt hier mit drei Stufen arbeiten (Niedrig, Mittel, Hoch) oder mit den Fibonacci-Zahlen bis 144. Wer möchte, kann natürlich gerne Farben hernehmen. Hauptsache, die Stufen sind für alle verständlich und nachvollziehbar.
Teil 4: Die Aufwandsschätzung/Komplexitätsschätzung
Fassen wir mal eben kurz zusammen:
Die Userstory steht und folgt dem INVEST Schema, die Abnahmekriterien sind definiert und worin genau der Mehrwert liegt, steht ebenfalls fest. Im letzten Schritt steht die Aufwandsschätzung des Teams für die Story Cards an.
Dabei geht es allerdings nicht um Stunden oder Personentage, denn auch hier sollen Stories miteinander verglichen werden. Auch sagt sie nichts über den Umsetzungsweg (dieser soll offen bleiben), denn jeder Umsetzungsweg bedeutet einen anderen Aufwand.
Hier machen sich die „angepassten“ Fibonacci-Zahlen (…, 8, 13, 20, 40, 100) ziemlich gut:
Story A ist gefühlt doppelt so komplex, wie Story B. Oder Story C wird definitiv ein kleines bisschen aufwändiger sein als Story D.
Natürlich kann diese Aufwandsschätzung erst dann vorgenommen werden, wenn zuvor alle Fragen mit dem Umsetzungsteam geklärt worden sind.
Verwendet man die Fibonacci-Priorisierung, lässt sich daraus bspw. ableiten, dass Stories mit 40 oder 100 Storypoints per Definition episch und daher zu komplex, bzw. zu groß sind, um in einem Sprint umgesetzt werden zu können. Hier muss man nochmal ran und sie z.B. splitten und in greifbare „Häppchen“ unterteilen, die besser in einen einzelnen Sprint passen.
Woher weiß ich jetzt, ob eine Story Card gut ist?
Neben den INVEST-Kriterien orientieren sich Ersteller von Story Cards gerne noch an diesen drei Aspekten: Card, Conversation und Confirmation
Card: Kurzfassen; Geschichten sollten auf eine Karte passen können.
Conversation: Anforderungen nicht einfach vorgeben, sondern immer zusammen mit dem Entwicklungsteam besprechen, um das Verständnis aller Beteiligten zu schärfen. Erst in einem Gespräch wird allen wirklich klar, was tatsächlich realisiert werden soll.
Confirmation: Akzeptanzkriterien prüfen, ob eine Story „Done“ ist. Auch hier sollte im Gespräch ein gemeinsames Verständnis der Definition-of-Done geklärt werden. So lassen sich am Ende eines Sprints Missverständnisse vermeiden.
Was macht man, wenn die Story zu groß ist?
Es kommt in der Praxis häufig vor, dass eine Idee für einen Mehrwert zu groß für einen einzigen Realisierungs-Sprint ist, oder das Team sich nicht sicher ist und sich nicht zu 100% sich dazu committen kann, weil ggf. noch andere Themen im Alltag anstehen. Da ist es hilfreich, kurz durchzuatmen, einen Schritt zurückzugehen und nochmal zu prüfen:
- Passt die Story wirklich ins INVEST-Schema?
- Was ist der größte Nutzen? Gibt es einen simplen Kern, der den größten Mehrwert beinhaltet?
- Weniger Komplexität: Ist das Weglassen von Optionen und das Vereinfachen von Oberflächen eine Lösung?
Wer beim Lesen mindestens einmal nicken musste, sollte die Story am besten aufsplitten und sie nach Aktionen, Operationen oder Funktionen aufteilen, die die User separat ausführen können.
Story Cards: Definition-Of-Ready
Viele Teams überlegen vorab gemeinsam (und ergänzen in ihren Retrospektiven), was eine Story Card wirklich vollständig macht und ob alle gut damit arbeiten können. Genau das wird festgehalten und in einer Definition-of-Ready für alle transparent zusammengestellt. Es hilft insb. dem Productowner, die Story Cards nochmal gegenzuprüfen, ob sie auch wirklich Ready sind, ehe sie zum Entwicklungsteam zur Einschätzung kommen.
Weitere Tipps für Story Cards:
- Niemals ungeschätzte Stories in einen Umsetzungssprint aufnehmen
- Holt Euch immer Feedback und Fragen vom Umsetzenden, bzw. Umsetzungsteam (vor Umsetzungen und Aufwandseinschätzungen) ab, denn diese zeigen oftmals noch vorhandene Lücken auf.
- Die Umsetzenden besprechen intern, wie genau sie die Story umsetzen möchten und legen dazu Subtasks an. Oft entstehen hier noch Abhängigkeiten zu anderen Personen, die es anfangs zu klären gilt (wann, wer, wo, …).
- Grundsätzlich gilt, dass die Story innerhalb eines Sprints umsetzbar sein muss. Allerdings passiert es oft, dass Stories doch zu groß für einen Sprint sind. Gewöhnt Euch an, große Stories zu splitten. Das kann funktionell sein, das kann technisch intern sein. Es muss aber immer ein Mehrwert für eine Nutzerrolle übrigbleiben. Das ist meist nicht einfach und erfordert etwas Routine.
- Den Aufwand mit der genauen Ausformulierung von Abnahmekriterien etc. erst vornehmen, wenn die Wahrscheinlichkeit hoch ist, dass es zu einer Umsetzung kommt.
Habt Ihr vielleicht schon mit Story Cards gearbeitet? Wie sind Eure Erfahrungen damit? Wie gestaltet Ihr gute Story Cards, damit die Umsetzung erfolgreich klappt?