Wie schreibt man User Stories richtig?

Was ist eine User Story? Was sind die User Story Vorteile?
Es ist immer wieder faszinierend, wie viele Missverständnisse es zu einem eigentlich recht einfachen Konzept geben kann. Die Bedeutung von User Stories ist in agilen Projekten meist überschätzt – und doch kann dieses Format etwas, das hilfreich ist für echte Nutzer-Empathie.
Wir bringen User Story Beispiele und zeigen auch, wie sie in Scrum verwendet werden können.

Kai

User Stories werden oft im gleichen Atemzug genannt mit agilen Methoden und wir kümmern uns heute um ein paar Mythen, denn die werden ganz oft falsch verwendet und du kriegst in diesem Podcast mit. Was ist eine User Story und wie schreibt man die eigentlich richtig? Und wie spart man unglaublich viel Zeit beim User Story schreiben denn falls du da eine riesen lange Liste gerade vor dir hast, die so eine Anforderung ausmacht, dann haben wir da eine kleine Überraschung für dich in petto.

 

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agile Growth Podcast. Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT WIssen vorauszusetzen.

 

Jasmine

Ganz, ganz oft, wenn wir beim Kunden unterwegs sind – ob jetzt in der IT oder nich, in der IT kriegen wir so was zu hören wie: Ja, wir machen ja jetzt auch dieses Scrum. Wir benutzen Jira und schreiben User Stories. Aha, okay. Und was hat das jetzt konkret mit Scrum zu tun? Grundsätzlich schon mal gar nichts, oder wir kriegen die Fragen. Ja, irgendwie sagt das Management jetzt, wir dürfen nur noch User Stories schreiben, aber ich weiß gar nicht, was das ist.

 

Jasmine

Dieser Begriff User Stories, der geistert so durch die Hallen und Räume, sobald irgendjemand anfängt Agil zu arbeiten oder mit Scrum zu arbeiten. Und wenn du noch nicht so viel damit zu tun hast. Ganz kleiner Disclaimer an der Stelle – Jira ist Ticket Management Tool, das ganz viel kann. Viele Firmen benutzen es. Man muss das nicht benutzen um Scrum zu tun, aber man kann gibt es in gut gibts in nicht so guter Implementierung gibt es in It, gibt es nicht in IT.

 

Jasmine

So, das dürfen wir gerade mal vergessen, weil das hat nichts mit Agilität zu tun. Also welches Werkzeug ich benutze, hat ganz ganz wenig damit zu tun wie Agil ich bin und ob ich User Stories schreibe oder nicht, hat auch ganz wenig damit zu tun wie agil ich bin. Aber die meisten Teams, die Agil eine Produktentwicklung vorantreiben, werden irgendwann mal für sich ein Backlog erstellen. Und ein Backlog ist eine geordnete Liste an Anforderungen an unser Produkt. Und in diesem Backlog sind natürlich Einträge.

 

Jasmine

Und da hilft es mir, eine gewisse Idee davon zu haben, wie ich diese Einträge schreiben kann. Und wenn ich jetzt gucke, was steht denn normalerweise so in den Backlogs, dann sind das nicht nur User Stories, weil das ein sehr spezifisches Format ist, das aber durchaus Sinn macht. Deswegen wollen wir ganz, ganz explizit auf dieses Format eingehen in diesem Podcast. Aber bevor wir da hin kommen, vielleicht noch was kann sonst noch so in dem Backlog drinstehen?

 

Jasmine

Da können zum Beispiel natürlich auch Fehler an unserem Produkt drin stehen. Das werde ich nicht unbedingt in diesem Format User Story machen. Da können System-Anforderungen drinstehen, oder da kann auch technische Schuld drinstehen. Wenn ich schon lange irgendwas an diesem Produkt mache, dann habe ich vielleicht irgendwo Schuld aufgeladen. Das wird auch irgendwie beschrieben sein, aber vielleicht nicht unbedingt in diesem User Story Format. Warum dieses User Story Format aber trotzdem sehr, sehr hilfreich ist, hilft vielleicht, wenn man mal zurück guckt wo kommt Agilität her oder wo kommt Scrum her und es kommt aus der IT und da hat man ein Format gesucht, das den Entwicklern hilft.

 

Jasmine

Im Prinzip Empathie zu entwickeln mit dem Endnutzer.

 

Kai

Wir haben das mittlerweile in unserer Produktentwicklungskultur viel viel mehr drin. Es gibt ja so Leute, die sich darauf spezialisieren, UX genannt, also User Experience, die sich da ganz viel mit beschäftigen. Wie erlebt eigentlich unser Anwender das Produkt oder das System? Und wenn man so ein bisschen zurück guckt, damals gab es das halt nicht in der Form und ich habe ja auch Informatik studiert und bei mir war das am Anfang auch so. Ich als Programmierer habe ganz viel gedacht in so inneren Repräsentationen von meinem Produkt.

 

Kai

Also sprich eher so auf der Ebene von Quellcode und Abstraktionen und Schichten und Datenbank-Layer und all diesen Dingen, die ich als Informatiker eben kann. Damit war ich aber relativ weit weg von dem Problem meines Anforderers, also dem Problem meines Kunden, sondern war eher so in diesem Lösungs-Gebäude drin. Und insofern ist das praktisch für mich, wenn ich als derjenige, der das umsetzen soll, noch mal in den Hautsack des anderen rein schlüpfen kann, desjenigen dessen Probleme lösen will, also unserem Kunden und da mehr verstehe, was will der eigentlich und wieso überhaupt?

 

Kai

Und jetzt haben wir ja auch festgestellt, dass das ganz ganz schwierig ist, in Textform irgendwie Anforderungen aufzuschreiben, also so ein Fein Konzept aufzuschreiben, wo ganz detailliert Details drin stecken, weil das so ein bisschen dieses Flüster-Post Spiel ist, wo man ganz ganz viele Dinge miteinander verzahnt. Und da helfen uns eben User Stories etwas anderes zu tun.

 

Jasmine

Und in meiner Erfahrung ist es eigentlich egal, ob du jetzt in der IT unterwegs bist oder in einer anderen Branche unterwegs bist. Dieses sich in die Schuhe des End-Nutzers zu begeben ist unglaublich schwierig. Also selbst wenn ich jetzt irgendwie im Human Resources unterwegs bin, eine Trainings-Organisation habe, dann hilft es mir einfach durch ein Format gezwungen zu sein vom Endbenutzer her zu denken, weil wie oft kommt das vor? Und das kommt bei mir ganz ehrlich ganz oft vor, dass ich eine geniale Idee habe.

 

Jasmine

Und die ist so genial, dass ich anfange Anforderungen aufzuschreiben. Wie wir diese Idee jetzt umsetzen und in meinem Anforderungen aufschreiben. Wie wir diese Idee umsetzen, vergesse ich komplett zu beachten: für wen ist denn das eigentlich? Und der Punkt von genialen Ideen ist ganz oft – Die entspringen ja aus unseren eigenen Bedürfnissen. Aber mein Bedürfnis ist nicht unbedingt das Bedürfnis meines Nutzers oder meines Kunden. Also wenn ich – und wir geben ja ganz viele Scrum Master Trainings – wenn ich ein Scrum Master Training gebe und ich da eine geniale Idee habe und anfange runter zu schreiben, wie muss ich denn das jetzt genau umsetzen?

 

Jasmine

Was für Material brauche ich und so weiter. Dann kommt Kai ganz oft und sagt mir: Du Jasmine. Was soll denn ein jemand, der neu mit Scrum einsteigt, dabei überhaupt lernen? Da bin ich bisschen sauer auf Kai, aber die Frage ist gut, weil oft ist es ja meinem Bedürfnis entsprungen und viel zu weit weg von dem, was ein Nutzer bräuchte.

 

Kai

Und da hat sich jetzt ne User Story als hilfreich erwiesen. Und machen wir’s mal konkret: Was ist das eigentlich? Wir haben es gerade gehört. Das ist eine Art Empathie-Hilfe, so eine Story. Das ist aber eigentlich ein natürlich-sprachlicher Satz, also ein Stückchen Text, das irgendwie beschreibt: Wer möchte was wozu? Und so nutzen manche auch ein bisschen, wie so die Stützräder am Fahrrad, wenn man Fahrradfahren lernt, eine Zeit lang so ein Format und das nennt sich „als wer möchte ich was um wozu?“ Also zum Beispiel könntest du sagen: Als Agile Growth Podcast Hörer möchte ich verstehen, was eine User Story ist, um

 

Kai

Bald in meinem Arbeitsalltag diese sinnvoller nutzen zu können. Dann hätte ich also festgelegt, wer möchte das haben, nämlich du als unser Hörer? Muss ich vielleicht noch ein Bild innerlich haben – wer bist du als unser Hörer? Also Jasmine ich machen uns so eine Vorstellung davon. Wie siehst du jetzt aus? Wo hörst du uns gerade beim Kochen oder beim Fahrradfahren? Und dann haben wir das „wer“ klar. Und dann das „was“. Was ist eigentlich das, was da gebraucht wird?

 

Kai

Die Funktionalität, das Bedürfnis dahinter? Und wozu? Was ist denn die Absicht? Was möchte derjenige, wenn er dann diese Funktion hat? Und das alles wird eben beschrieben. Und du merkst schon bei diesem Ganzen, wie lange man darüber sprechen kann. Es ist eigentlich ein Satz, der ein Versprechen über ein Gespräch darstellt. Also der ist so unkonkret, dass ohne weitere Unterhaltung darüber,  man das auch gar nicht umsetzen kann.

 

Jasmine

Wobei der aber auch so konkret ist, dass das bei mir schon ganz, ganz viele Ideen triggert, nämlich als Kai gesagt hat: Wer will das, unser Podcast Hörer? Da brauchen wir vielleicht ein inneres Bild von und dann hat Kai schon gesagt: Ja, warum hörst du das? Vielleicht beim Kochen oder beim Fahrradfahren? Ah, spannend. Okay, das heißt, du hast keine Möglichkeit, was aufzuschreiben. Du wirst da nichts neben dir haben. Und stimmt, wir gehen davon aus, dass niemand von euch oder dass du auf jeden Fall nicht an deinem Schreibtisch sitzt und jetzt etwas schreiben möchtest.

 

Jasmine

Das heißt, wir werden die Information so verpacken müssen, damit sie leicht konsumierbar ist – um was geht es wirklich? Um das Verständnis einer User Story. Und dann macht das bei mir auch schon wieder ganz ganz ganz viele Knöpfe auf. Oh, müssen wir dann was zum Backlogs verstehen, was ich vorher schon angedeutet habe, oder? Oder nicht? Oder wo geht das hin? Und der schwierigste Teil ist immer das: Wozu möchtest du das verstehen?

 

Jasmine

Wir haben jetzt angenommen, damit du das besser in deinem Arbeitsalltag umsetzen kannst, das heißt, wir brauchen auch ganz konkrete Umsetzungs-Tipps in dieser Podcastfolge drin. Also, wie du siehst, es ist ein Satz, der aber so viele Informationen enthält, dass es bei mir schon die Kreativität schürt. Das heißt, kann ich das direkt von diesem Satz irgendwie in die Umsetzung gehen? Nein, es ist schwierig, aber ich kann mit Kai drüber anfangen zu reden. Wie muss denn diese Podcastfolge jetzt konkret aussehen, damit sie den Nutzen generiert

 

Jasmine

den wir generieren wollen?

 

Kai

Also das Ding öffnet quasi einen Korridor von Kreativität. Und wenn man dabei natürlich Details herausfindet, dann darf man die auch aufschreiben und dann kann man entsprechend festlegen wann ist denn diese User Story fertig? Und eine ganz nette Merkhilfe sind die drei C dabei. Also das erste C ist Englisch für Card. Also eine User-Story passt auf eine Karteikarte. Das heißt also wirklich, das ist ein kurzer Satz. Das ist nicht eine halbe DIN A4 Seite geschrieben, sondern einfach mal so ein halber Satz

 

Jasmine

Und mit einem dicken Stift.

 

Jasmine

Also nicht eine Karteikarte mit so einem dünnen Bleistift. Es ist eine Karteikarte mit einem dicken Stift.

 

Kai

Das zweite ist in der Story selber steckt ja gar kein „Wie“ drin. Also ich habe da drin. Wer möchte was? Wozu? Ich habe kein Wie drin. Das heißt, dass ganz viel Musik da drin wie die Lösung aussieht. Und das hat Jasmine ja gerade auch schon angesprochen, wie genau das umgesetzt wird, zum Beispiel hier die Podcastfolge ist ja dann etwas, was sich durch den Raum unserer Kreativität füllt. Und dann sind wir beim zweiten C und das steht entsprechend für Conversation.

 

Kai

Also eine User Story führt zu einem Gespräch. Wenn man das jetzt in der Praxis sieht, wie machen das dann Agile Teams? Die haben ein Gespräch im Idealfall zwischen ihrem Anforderer, also dem Kunden und den Entwicklern. Also Fachexperten und Entwickler müssen täglich zusammenarbeiten, steht im agilen Manifest – da trifft das also aufeinander, nicht nur im heterogenen, cross-funktionalen Team, sondern auch mit den direkten Kunden-Dialogen. Also Scrum nennt sowas Backlog Refinement, also Backlogs Verfeinerung. Da, wo wir mehr verstehen, was genau bauen wir denn eigentlich?

 

Kai

Und dieses Gespräch ist eben wichtig. Und das, was wir dabei rausfinden, das halten wir fest im dritten C. Das steht nämlich für Confirmation. Also wie weiß ich eigentlich, dass diese User Story fertig ist? Wann sagt Tante Erna mir – Das ist immer so mein prototypischer Name für den Kunden, für das Gegenüber. Jemanden, der also nicht diese ganze Technologie versteht oft, sondern einfach so eine Fach-Domäne. Wann sagt er, ist das fertig?

 

Kai

Wann akzeptiert das mein Kunde als abgeschlossen? Akzeptanz-Kriterien könnte man das auch nennen. Wann ist diese User Story fertig? War das unsere Podcastfolge fertig? Zum Beispiel wenn du ganz konkretes Wissen bekommen hast und konkrete Tipps, wie du das anwenden kann, bei dir könnte. Bei uns, das Confirmation Kriterium sein.

 

Jasmine

So, jetzt hast du schon gehört, was ist diese User Story? Wie baut sich die auf? Es ist ein Satz, der diese drei Aspekte – wer möchte was und wozu – abdeckt. Und die drei Cs als Merkhilfe: Card, Conversation und Confirmation im Sinne von wie setze ich das um? Oder was ist wichtig dabei, wie wir das jetzt meistens angehen ist – Wir schreiben eine sehr, sehr große User Story. Wir könnten eine User Story für diesen Podcast schreiben. Als Agile Growth Podcast-Hörer möchte ich gerne sehr viel Input zu Agil, damit ich meinem Wachstum begleitet werde.

 

Jasmine

Wäre wahrscheinlich unsere User Story für diesen Podcast und die ist noch relativ schwach, weil dies gerade so aus meinem Kopf entsprungen, die dürften wir jetzt schärfen. Und darunter kann mir natürlich dann ganz viele User Stories für jede einzelne Podcastfolge machen. Und wir könnten sogar noch mehr vertiefen, indem wir ganz viele User Stories für die einzelnen Kapitel einer Podcastfolge machen und somit eine Struktur da reinbringen. Das heißt, ich kann die User Stories auch immer wieder, man nennt das dann splitten, kleiner machen, Teilaspekte davon rausnehmen.

 

Jasmine

Das ist so was, was man zum Beispiel in einem User Story Map machen würde, was wiederum einfach nur eine Empathie-Hilfe ist, um von dem Endnutzer auf das ganze Produkt zu gucken. Und das ist natürlich ein bisschen einfach, wenn ich jetzt ein Softwareprodukte habe, weil ich das einfacher beschreiben kann. Aber ich habe das auch schon bei Lern-Produkten gemacht. Vom Ende User auf die gesamte Lern-Reise zu gucken, die jemand macht, wenn er in ein Training geht oder wenn er in eine ganze Trainings Serie geht.

 

Jasmine

Aber man kann das auch nur mit einem Training machen. Was geschieht vorher? Was geschieht nachher? Von dieser End User Perspektive aus? Und da steckt ganz viel – wir sind dann ganz viele nennen das ein Problem Raum. Wir beschreiben den Problem Raum sehr sehr genau, damit wir kollektiv mit unserer kollektiven Intelligenz als Team in den Lösungsraum gehen. Das heißt wir möchten als Userstory nicht unbedingt haben. Als Nutzer der Software, was sowieso eine sehr sehr sehr schwache Persona wäre, möchte ich, dass dieser Button grün wird, damit ich ihn besser sehe.

 

Jasmine

Das wäre ja schon eine Lösung. Was ich da vielleicht haben könnte ist als Barbara Backoffice möchte ich, dass die Buttons in der Software gut sichtbar sind, weil ich wenig Zeit habe, wenn ich die Software bediene und gleichzeitig am Telefon bin. Das heißt, ich habe da keine Lösung drin. Ich sage nicht, es kann ja sein, dass der Button grün wird, aber ich weiß, warum Barbara Backoffice das will. Ah ja. Barbara Backoffice ist gleichzeitig am Telefon und muss rum tippen und hat wenig Zeit.

 

Jasmine

Und die hat auch nicht Zeit, da drauf zu gucken. Das sag dem oder derjenigen, die dann das Design und in die Lösung geht, so viel mehr aus als „es muss grün sein, damit ich sehen kann.“

 

Kai

Und jetzt gibt es immer wieder diese Frage, die kriegen wir auch in Trainings ganz oft. Wie schreibe ich denn dann jetzt eine gute User Story? Und im Prinzip, wenn du diese Frage hast, könntest du auch sagen – dann gibt es wahrscheinlich ein Problem in der Beziehungsqualität zwischen den Anforderern und deinem Team. Denn eigentlich geht es hier um dialog-basierte Produktentwicklung. Dieser kleine Fetzen Text, der da auf so einer Karte drauf steht, der soll einfach nur zum Dialog anregen. Das heißt, von der Formulierung her ist es eigentlich total egal, wie du so ein Ding aufschreibst.

 

Kai

Und es geht nicht darum, da einen ewig langen Monolog zu machen. Und das sieht man auch manchmal in Teams, die noch neu sind, in Agilität oder wenn wir so reinkommen im Coaching. Die schreiben dann seitenweise Anforderungen in Tickets rein und das sind dann deren User-Stories. Oben steht so ein Satz als soundso und so möchte ich das und das. Und darunter kommt dann Spezifikation nach Spezifikation nach Spezifikation. Und da merkst du, dann fangen die Teams auch an zu chatten über irgendwelche Tickets und schreiben dann da Kommentare rein und so weiter und entgehen dabei dem Dialog und andere Teams, die das sehr Agil tun, die wissen, dass die wichtigste Art der Kommunikation von Angesicht zu Angesicht stattfindet, weil wir eben so viel mehr an Bandbreite haben, an Informationen, die wir im direkten Dialog miteinander haben.

 

Kai

Dass wir die nutzen wollen, um ein möglichst tiefes Verständnis zu haben, um das richtige an Wissen zu produzieren. In unserem Quellcode zum Beispiel. Quellcode ist ja auch so amalgamisiertes Wissen und in unserem Produkt soll die bestmögliche Lösung rein fließen . Und die kriege ich dann hin, wenn die Leute, die das Produkt brauchen, mit denen sprechen, die das bauen und nicht wenn ich eine Abstraktionsschicht habe von Text.

 

Jasmine

Und um das noch mal zusammenzufassen – Es ist nicht schlimm, wenn die Spezifikationen irgendwo stehen. Das Schlimme daran ist, wenn sich das irgendjemand ausgedacht hat und hingeschrieben hat. Das heißt oder das schlimme daran, wenn sie schon in der User Story drin stecken. Die User Story soll der eine Satz sein, der unsere Kreativität anregt. Also als Barbara Backoffice möchte ich gut sichtbare Buttons, weil ich wenig Zeit zur Bedienung habe, wenn ich am Telefon bin. Und da kann das sein, dass wir jetzt in die in die Kommunikation gehen, miteinander, aber vielleicht auch mit prototypisch Barbara Backoffice.

 

Jasmine

Vielleicht fragen wir einfach drei Backoffice Mitarbeiterinnen. Wie sieht denn das aus, wenn du damit arbeitest? Und da sehen wir: Boah, die haben irgendwie sieben Fenster gleichzeitig auf, wenn sie am Telefon sind, müssen alle Programme gleichzeitig bedienen und dann halt unser Programm auch noch. Und dann brauche ich vielleicht eine Telefonansicht. Dann geht es gar nicht darum, dass wir einzelne Buttons umgestalten, sondern es geht darum, dass wir eine Telefon Ansicht des Programms machen oder oder oder oder.

 

Jasmine

Oder es geht einfach darum, dass wir den Button wirklich grün machen. Das würden wir in der Kommunikation mit dem Endkunden rausfinden und in der Kommunikation miteinander. Und wenn wir darüber reden und uns das dann aufschreiben, dann ist das was ganz anderes, als wenn das jemand aufgeschrieben hat, ich das lese. Und das führt oft zu ganz vielen Missverständnissen. Deswegen ist dieser Konversation Part ganz, ganz wichtig in einer empirischen Produktentwicklung. Wir schaffen hundertprozentige Transparenz, damit wir inspizieren und adaptieren können.

 

Jasmine

Das können wir nur zusammen, nicht alleine.

 

Kai

Wir hatten hier mal ein Interview mit Marc Bless, der hat auch mal ein Buch geschrieben über Scrum in der Medizintechnik. Jetzt könnte man ja sagen: Okay, aber wenn jetzt in diesen User Stories nicht so richtig spezifiziert ist, was wir bauen sollen, kann ich das zum Beispiel Medizintechnik Bereich machen, Agil arbeiten oder kann ich das im Luft und Raumfahrt Bereich machen? Wenn ich ganz konkrete Dokumentation brauche, gehört die einfach an eine ganz andere Stelle nämlich, dann verorte ich die in einem Scrum Rahmenwerk in der Definition Of Done, also dem Kriterium, was fertig heißt.

 

Kai

Da kann dann durchaus drinstehen, wir haben irgendeine ISO Norm erfüllt. Und an der Stelle ist vielleicht auch ganz viel textliche Dokumentation entstanden, die das noch mal für die Nachwelt irgendwie verfasst. Es ist aber einfach dann andersherum. Es ist quasi ein Liefer Gegenstand, der nachher aus der Kreativität am Anfang entstanden ist und nicht andersherum. Dass ich mir vorher ein riesen Kopfzerbrechen als ein einzelner Experte, was genau die beste Lösung sein soll. Und danach ein Team, das nur noch umsetzt, sondern eben dieses Führen über die Einladung zum Gespräch.

 

Kai

Insofern kann man auch sagen Agile Teams quatschen viel mehr.

 

Jasmine

Aber dadurch bauen wir das Richtige in der richtigen Qualität und reduzieren sehr, sehr, sehr viel Waste auf dem Weg. Das heißt, das kann sich anfangs uneffizient anfühlen, weil ja, wir gehen viel mehr in den Dialog. Das ist aber hinten raus oder mittelfristig sehr viel effizienter, weil wir den ganzen Quatsch und die ganzen Missverständnisse eben nicht mehr bauen, sondern früher rausfinden. Um das jetzt noch mal so zusammenzufassen. Viele Agile Teams haben ein Backlog, eine geordnete Liste an Anforderungen an das Produkt.

 

Jasmine

Da können ganz viele verschiedene Dinge drinstehen, unter anderem User Stories. Nicht alles was da drinsteht, ist eine User Story, auch wenn Jira das so nennt. Wenn ich zum Beispiel eine System Beschreibung da drin habe, weil das System das einfach braucht, dann bitte nicht als User Story formulieren. Es gibt ganz komische User Stories. Wenn ich aber einen konkreten Umsetzungwunsch ein Feature da drin habe, dann nützt mir die User Story unglaublich. Wenn ich da eine User Story schreibe, ist das nur ein Versprechen für eine Konversation.

 

Jasmine

Das heißt das ist eine Anforderung an unser Produkt. Wirklich aus der Brille des Endkunden raus geschrieben, das uns helfen soll in Konversationen zu gehen und unsere kollektive Intelligenz und Kreativität zu nutzen. Sobald wir in Konversation gegangen sind, können wir natürlich spezifische Anforderungen an diese User Story dran schreiben. Dann werden wir uns auch alle erinnern, was wir uns überlegt haben. Das sind dann die sogenannten Akzeptanz-Kriterien. Also wie teste ich, dass wir fertig sind mit dem was wir denken, dass unser End-User braucht?

 

Jasmine

Eine User Story ist nichts anderes als eine Hypothese und es bleibt eine Hypothese, bis der User das getestet hat und sagt – Jo, das ist das was ich brauche oder noch nicht ganz. Und beides ist okay. Wir sind in einem komplexen Raum, das heißt, wir können nicht immer alles 100 Prozent perfekt haben. Das ist einfach natürlich. Wir müssen vielleicht noch mal zurückgehen ans Reißbrett, noch mal ein bisschen was ändern an unserer Idee schleifen, noch mal ausliefern. Und beim zweiten oder dritten Mal sagt unser End User Genau das habe ich gebraucht.

 

Jasmine

Also Akzeptanzkriterien sind die konkreten Anforderungen, die wir besprochen haben an unsere User Story. Und dann habe ich noch die Definition Of Done, unsere gemeinsame Anforderungen an Qualität für jede einzelne User Story und für jedes einzelne Ticket in unserem Backlog. Das heißt, das gilt über alles hinweg. Alle Anforderungen, die ich habe an Dokumentation, an Qualität etc. steht in unserer Definition Of Done. Da haben wir auch eine Podcastfolge dazu gemacht. Aber jetzt hast du so trennscharf die unterschiedlichen Abgrenzungen.

 

Jasmine

Die sind am Anfang ein bisschen schwierig zu verstehen. Sobald man anfängt, damit zu arbeiten, macht es aber ganz, ganz viel Sinn, warum das getrennt ist und warum wir da sehr trennscharf unterwegs sind.

 

Kai

Diese Themen vertiefen wir natürlich auch in unserem Certified Scrum Master Seminar und auch im Advanced Certified Scrum Master Seminar noch mal, dass du diese gleiche Klarheit und auch noch so das Handwerkszeug dazu lernst, damit du einen Product Owner darin auch unterstützen kannst, das entsprechend zu nutzen. Und wir hoffen, du hast jetzt einen guten Überblick gekriegt über das Thema, denn eigentlich wird das viel zu heiß gekocht, als es gegessen wird. Denn ja, es geht darum, miteinander zu sprechen, das Richtige zu bauen klingt trivial, ist aber in der Praxis ganz oft nicht der Fall.

 

Kai

Insofern die große Einladung zum Gespräch, die wir hier heute aufgemacht haben mit dir. Und wir freuen uns, dass du in dieser Folge wieder zugehört hast beim Agile Growth Podcast.

 

Jasmine

Das war unser kleiner Impuls zum Thema User Stories. Wenn du Leute kennst, die User Stories falsch benutzen oder noch viele Fragen haben zu genau diesem Thema, dann darfst du diesen Podcast natürlich unglaublich gerne weiterempfehlen. Und ich freue mich total, wenn du nächstes Mal wieder mit dabei bist beim Agile Growth Podcast.

 

User Stories verständlich erklärt

 User stories in Oxford - (c) Jacopo Romei CC-BYSobald man Software entwickelt, stellt sich die Frage, wie man eigentlich mit Wünschen und Ideen von Entwicklern, Kunden, Führungskräften, Produktmanagern, also den Stakeholdern umgeht.

Schreibt man alles in ein Word-Dokument mit sauberer Gliederung? Nutzt man Skizzen oder Prozessmodellierungswerkzeuge? Machen wir ein Grobkonzept, dann ein Feinkonzept, stimmen es mit dem Kunden ab und fangen dann an zu arbeiten? Oder doch eine Excel-Tabelle oder einen Projektplan mit Tätigkeiten?

Eine beliebte Variante zur Arbeit mit Anforderungen in agilen Projekten nennt sich „User Story“: Eine User Story sind wenige Sätze natürlicher Sprache, um als Gedankenstütze für eine Anforderung zu dienen.

Ein Beispiel für eine User Story:

Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.

Könnte das Team diese Anforderung umsetzen? Vermutlich nicht. Die beschriebene Anforderung ist  recht vage, nur grob umrissen. Eine Idee, die es zu durchleuchten gilt. Das Grundprinzip dahinter: Ein guter und kontinuierlicher Dialog der Beteiligten ist wichtiger als eine detaillierte, niedergeschriebene, im Voraus für das Projekt völlig durchdrungene Spezifikation.

Man kann sich so eine User Story wie ein „Aufhänger für eine Funktionalität“ vorstellen. Die Funktionalität wird sichtbar, anfassbar, begreifbarer. Aber eben nicht vollständig definiert.  Das verhindert allein schon die Unschärfe von Sprache und auch die Komplexität von Softwareentwicklung. Besser wir investieren hier nicht allzuviel Zeit.

Doch mit so großer Unschärfe kann auch das beste Team der Welt nicht wirklich effizient arbeiten. Die User Story enthält zwar wer was warum möchte – aber nicht was genau und schon gar nicht wie genau.

Vom Groben ins Feine.

Wann wird solch eine Idee namens User Story nun also konkreter? Kurz bevor wir die umschriebene Anforderung der User Story umsetzen möchten, sollte sie klein und konkret sein. Um dahin zu gelangen, machen agile Teams häufig so genannte Backlog Refinement Besprechungen. In diesen Besprechungen geht es darum, das Verständnis zu vertiefen und gemeinsam mit dem Product Owner, große User Stories in kleinere zu zerlegen.

 Prioritizing user stories - (c) Jacopo Romei CC-BY - https://www.flickr.com/photos/jakuza/3578548023Spätestens wenn ich eine User Story in eine Iteration reinnehmen möchte, sollte sie also gut verstanden sein, vielleicht auch schon kurz davor. Das bedeutet, dass das Entwicklungsteam weiß, was das Ziel der Umsetzung ist und woran es erkennen kann, dass es dieses Ziel erreicht hat. Häufig sind dann auch weitere Wissensquellen als Anlagen zu einer User Story vorhanden: Vielleicht ein UI-Entwurf, vielleicht eine Spezifikation eines Gesetzgebers, vielleicht Formeln in einer Excel-Tabelle. Hier ist erlaubt, was dem Team hilft – ohne es von Beginn an in seiner Kreativität und Lösungsfindung einzuschränken.

Ich bin fertig und mache dann mal Feierabend für heute.

Woher weiß ein Team nun, ob es das Ziel einer User Story erreicht hat? Wann ist die Funktionalität fertig? Das klärt das agile Team im Dialog mit seinem Product Owner. User Stories werden während dieses Dialogs häufig durch schriftliche Akzeptanzkriterien ergänzt. Das sind stichpunktartige Kriterien, die erfüllt sein sollten, damit der Product Owner eine User Story als fertig akzeptiert. Eine Art Checkliste oder für diese eine User Story geltende Ergänzung der Definition of Done.

Ein Beispiel:

Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.

Akzeptanzkriterien:
– Die Liste zeigt alle noch nicht verkauften Fahrzeuge an
– Die Liste ist nach Kaufpreis sortiert
– Wenn keine Fahrzeuge vorhanden sind, erscheint ein Hinweistext

(c) CC-BY https://www.flickr.com/photos/psd/8591351239Die User Story bleibt dabei auf der Ebene der Benutzerperspektive: Sie sollte also von allen Menschen mit Domänenhintergrund verstanden werden können – und deswegen auch nicht technisch sein. Gedanklicher Kniff: Stellen Sie sich vor, ein Kunde ohne technischen Hintergrund sollte sie verstehen können. Eine Kommunikationsbrücke zwischen Entwickler und Fachperson also.

Ein bisschen mehr Technik bitte.

Wann wird es nun endlich technisch? Wo entsteht die Lösungsidee? Welche Architektur braucht es und welche Anpassungen im Code? Alle konkreten, technischen Tätigkeiten wird ein agiles Team in der Sprintplanung oder in einer Iteration selber identifizieren und als so genannte „Tasks“, also kleine Schritte zur Implementierung solch einer Anforderung, an eine User Story hängen. Das ist elegant, denn so sind fachliches Problem und technische Lösung bis zur Sprintplanung getrennt. Wir verwenden so nämlich keine Zeit auf technische Überlegungen, die vielleicht doch nie umgesetzt werden, weil sich die Marktanforderungen ändern und damit die Prioritäten unseres Backlogs.

Nun: Wie sähe wohl Ihr aktuelles oder nächstes Projekt mit dem Konzept von User Stories aus? Was wäre anders? Was schwieriger, was leichter? Viel Erfolg beim Ausprobieren.

User Stories einfach teilen – mit dem User Story Splitting Flowchart für Product Owner

Es ist eine Kunst, mit Anforderungen in IT-Projekten gut umzugehen. Denn agile Teams benötigen für ihre Arbeit klein geschnittene und gut definierte Features, damit sie diese in einem kurzer Zeitraum (wie z.B. einem Sprint) bearbeiten können.

Doch die Anwender moderner Anwendungen sind umfangreiche Features und Funktionen gewohnt, die eigentlich nicht in so kurzer Zeit wie einem Zwei- oder Vierwochenfenster umsetzbar sind.

Als Produktverantwortlicher (die Scrum’ler nennen sie Product Owner) könnte ich mir also die Frage stellen:

  • Wie schneide ich eine Anforderung richtig, damit mein agiles Team optimal damit arbeiten kann?
  • Wie zerlege ich große Features in kleinere, die unabhängig voneinander geplant und umgesetzt werden können?
  • Wie komme ich weg von der „alles ist Prio 1“ Sichtweise hin zu differenzierteren Betrachtungen und damit mehr Handlungsoptionen im konkreten Projekt?

Es gibt ein gutes Hilfsmittel, um diese Fragen zu beantworten, welches ich gerne im Agile Coaching einsetze: Richard Lawrence hat ein tolles Flowchart „Userstories aufteilen“ entwickelt, welches ich nun ins Deutsche übersetzt habe.

[dflip id=“4988″ ][/dflip]

Die Datei enthält den grundlegenden Workflow, wie man Stories zerlegt und beinhaltet die beliebtesten Muster dazu in einer übersichtlichen Darstellung. Hintergrundinformationen zu den einzelnen Pattern bietet Lawrence dazu auch nochmal in seinem Blog an.

Sie können es kostenfrei hier herunterladen (PDF-Format), um damit in Zukunft leichter User Stories zu zerteilen und Ihre Teams optimal zu unterstützen. Viel Erfolg beim Einsatz!

Story Points verständlich erklärt

Bei meiner Recherche im Internet und der gängigen Literatur habe ich gute Beispiele zur Vermittlung des Konzepts von Story Points gesucht.

Bis auf Mike Cohns Erläuterung in seinem Buch „Agile Estimation & Planning“ habe ich wenig leicht verständliches gefunden. Auf die Gefahr hin, dass ich vielleicht einfach eine gute Quelle verpasst habe und das Rad nun neu erfinde, möchte ich meinen Beitrag zu dem Thema zu leisten, um Story Points nochmal auf den Punkt zu bringen:

Storypoints sind eine Einheit, die die Größe einer User Story beschreiben.

Wie ist nun diese Größe definiert? Diese Frage ist nicht pauschal zu beantworten. Es fließen viele Faktoren ein, die von den Individuen abhängen, die diese „Größe“ definieren.

Ein Team könnte eine Größe zum Beispiel so definieren:

* Die Größe einer Story ergibt sich aus ihrer Komplexität. Die Komplexität hängt davon ab, ob und wieoft welche Schichten unseres Architekturmodells durchstoßen werden…

Ein anderes Team vielleicht so:

* Wie komplex sind die Interaktionen zur Umsetzung? Um diese Story umzusetzen müssen wir mehrere Abstimmungs- und Anpassungsrunden zwischen Designer, Interaction Designer und Frontend-Entwickler durchführen…

Wie auch immer ein Team diese Größe definiert, eines ist wichtig dabei: Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der „Struktur“ der User Story. Oder gleich um ein ganzes Bündel von diesen Eigenschaften.

Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.

Ein erfahrenes Team schafft einfach mehr bzw. größere Stories in der selben Zeit als ein unerfahrenes Team, das beeinflusst die Größe nicht.

Was bedeutet das nun für Schätzungen:

Die Diskussionen darüber, wer eine Story umsetzt, sind nichtig. Ob erfahrener oder unerfahrener Entwickler: Es spielt keine Rolle für die Schätzung einer Story. Das unterstützt cross-funktionale Teams in ihrer Arbeit und macht Schätzungen leichter und schneller. Es müssen nur die Eigenschaften identifiziert werden und ein Vergleich mit schon bearbeiteten oder ähnlichen Stories angestrebt werden, dann hat man die Größe.

Wie kann man nun mit Story Points einen Releaseplan erstellen?

Der Zeitfaktor kommt in Scrum dann durch die Teamgeschwindigkeit in das System. Diese so genannte Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration, also:

V = ø (SUM(Story Points der erfolgreich abgeschlossenen Stories im Sprint))

Wenn ich jetzt für alle Product Backlog Items Story Point Werte schätze, sie in der Reihenfolge durch eine Form von Priorisierung sortiere und weiß, wieviele Storypoints mein Team je Iteration umsetzt (Velocity), kann ich die Aussage treffen, in welcher Iteration ich ein Feature liefern kann.

Während der Arbeit entstehen also gemessene Zeitwerte, die ich dann auf die Größe appliziere. Zeiten schätzen wird daher mit Story Points niemand mehr. Das ist eine gute Konsequenz, wenn man überlegt, wie schwer es ist, so etwas komplexes wie die Entwicklung von Softwarebausteinen durch Zerlegung zeitlich abzuschätzen. Es gibt ziemlich dicke Bücher über nur dieses Thema und eher weniger als mehr Projekte, die gute Schätzungen vorweisen können.

Kleinteilige Diskussionen vermeiden

Ein anderer Aspekt ist der, dass durch die Betrachtung der Charakteristika einer Story vermieden wird, zu tief in die für die Umsetzung notwendigen kleinteiligen Elemente hineinzugehen. Die Merkmale einer Story können auch ohne eine detaillierte Tätigkeitenanalyse identifiziert werden. Das ist bei Aufwandsschätzungen in Tagen häufig anders. Hier werden alle notwendigen Tätigkeiten identifiziert und deren Aufwände aufsummiert.

Einfacher in der Praxis

In der Praxis ist das Thema „Story Points“ interessanterweise einfacher, als es tatsächlich zu erklären ist.

Nimmt man eine Referenzstory und einigt sich darauf, dass diese eine mittlere Größe hat, gibt das Team der Story zum Beispiel die Größe „5“. Andere Stories werden dann mit dieser verglichen und als gleich groß, kleiner oder größer eingestuft. Die Agilisten nehmen dann gerne die nach Mike Cohn angepasste Fibonacci-Reihe und verteilen die Elemente darauf: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Die seltsame Skala dient unter anderem dazu, auszudrücken, dass um so komplexer die Story ist (also umso größer), die Genauigkeit der Schätzung in die Binsen geht.

De facto sollte man mit sehr großen Stories vorsichtig in der Releaseplanung sein, denn es herrscht hier eine hohe Unsicherheit in Bezug auf das korrekte Verständnis des Teams für dieses Story – aber das ist ein anderes Thema.

Update vom 14.09.2018: Mit meinen Kollegen von DasScrumTeam habe ich ein kostenfreies Online-Video-Coaching produziert, das User Stories sehr anschaulich vermittelt.

Technische User Stories gehören nicht ins Product Backlog

Die agile Gemeinde hat dieses Thema schon öfter diskutiert – mit sehr unterschiedlichen Ansichten. Daher möchte ich diesen Beitrag nutzen, um meine Meinung darzustellen und sie zu begründen. Meine Erfahrung aus der Rolle des Entwicklers fließen in mein Verständnis ebenso ein, wie die wirtschaftliche Betrachtung der Softwareentwicklung.

Das Product Backlog ist ein Ort, an dem der Product Owner eine Bestellung an sein Team aufgeben kann. Häufig finden hier User Stories Verwendung.

Nach Mike Cohn haben User Stories die 3 C’s als Kriterien:

  • Card: Eine Story sollte auf eine Karteikarte passen.
  • Conversation: Eine Story ist keine vollständige Anforderung oder dergleichen. Es ist ein Versprechen über eine Konversation, die während der Planungssitzung und beim Estimation Meeting noch geführt werden soll.
  • Confirmation: Die Definition, wann eine Story erfüllt ist, sollte auf der Rückseite stehen in Form eines User-Acceptance-Tests, damit das Team weiß, welcher Maßstab im Review Meeting angelegt wird.

Würde ein Product Owner bei seinem Team bestellen, dass eine Komponente von Version 1.2 auf Version 1.3 aktualisiert werden soll? Möchte er diese Konversation mit seinem Team führen? Die Frage ist, ob dadurch ein Mehrwert für ihn aus Geschäftssicht entsteht: Braucht er ein Feature der Komponente, dass nur im neuen Release enthalten ist? Sind Fehler behoben, die den Anwender betreffen?

Jetzt wird der erfahrene Entwickler vermutlich auf die technische Schuld hinweisen. Vollkommen zurecht: Wer in größeren Projekten arbeitet, der kennt die Themen der Komponentenaktualisierung, umfangreicher Refactorings und Austausch ganzer Bausteine.

An dieser Stelle gibt es zwei Optionen:

a) Der Product Owner bestellt ein Feature, dass die Aktualisierung bzw. Bearbeitung der technischen Schuld tatsächlich auch beinhaltet. In diesem Fall werden entsprechende Tasks zu der User Story erstellt und wie gewöhnlich bearbeitet.

b) Der Product Owner interessiert sich eigentlich nicht für die notwendigen Tätigkeiten aber jeder gute Entwickler weiß, dass diese Veränderungen gebraucht werden, um das Fortbestehen und die Wartbarkeit der Anwendung zu sichern.

Das Team sollte im Sprint Planning dann entscheiden, wieviel Aufwand es erwartet in Bezug auf die technischen Veränderungen und dementsprechend das Commitment anpassen, dass es dem Product Owner gibt. In den Velocity / Burndown Graphen ist eine Anmerkung des Product Owners sinnvoll, warum eine vermutlich eingeschränkte Velocity nach der Iteration erreicht wird.

Dies ist eine kritische Stelle der Interaktion zwischen dem Team und dem Product Owner, denn dieser muß dem Team vertrauen, dass das Team wirklich nur die notwendigen Arbeiten in einem Rahmen durchführt, der es nachwievor ermöglicht, echten Geschäftswert zu schaffen. Nutzt das Team diese Entscheidungsgewalt als „technischen Freibrief“ aus, sollte der ScrumMaster diesen Konflikt thematisieren und lösen.

Nur ein verantwortlicher Umgang mit Ressourcen und ein Zusammenspiel aus Technik und Business sichern langfristig den Erfolg.

Machtkämpfe zwischen Produktverantwortlichen und Entwicklern oder Architekten haben hier keinen Platz.

Die Abarbeitung der technischen Tasks wird wie gewohnt im Sprint Burndown dargestellt. Hier herrscht also Transparenz für den Product Owner. Die kritische Frage, warum gewisse Tätigkeiten umbedingt erfolgen müssen, darf gestellt werden und sollte vom Team beantwortet werden ohne dabei eine Rechenschaft abzulegen. Das Team entscheidet selber, wie es produziert.

Hier kann es hilfreich sein, wenn der ScrumMaster beiden Seiten hilft, die Belange des jeweils anderen zu verstehen, für Transparenz zu sorgen und einen tragfähigen Kompromiss zu entwickeln. Ein farbliches Hervorheben von Tasks der „technical debt“ könnte eine Option sein, das Verhältnis für alle Transparent zu halten. Kippt das Verhältnis in die falsche Richtung, sollte es thematisiert werden.

Technische Stories gehören also nicht ins Product Backlog. Technische Tasks gehören hingegen zur Arbeit des Teams. Die Balance zu halten, liegt in der Verantwortung aller Beteiligter.