Wie schreibe ich eine User Story?

User Stories scheinen sich zu einer „State of the art“-Methode zur Formulierung von Anforderungen entwickelt zu haben. Kaum ein Buch über agile Softwareentwicklung, dass nicht auf diese Form der Beschreibung von Anforderungen verweist. Aber: Wie schreibt man eigentlich eine User Story?
Erst einmal zur Beruhigung: User Stories schreiben ist wie Fahrad fahren! Am Anfang ist es ungewohnt und fühlt sich seltsam an. Nach ein paar Versuchen läuft es dann aber wie von alleine und man verlernt es nie!

Nach über einem Jahr der Arbeit mit User Stories kann ich mir kaum noch vorstellen, wie ich mit meinen Teams vorher Anforderungen formuliert habe.

Grundsatz: Formulierung aus Sicht des Nutzers

Ein wichtiger Grundsatz bei User Stories ist, dass sie aus der Sicht eines Anwenders geschrieben werden. Daher werden sie auch frei von technischem Schnickschnack gehalten. Jeder, der am Projekt beteiligt ist, also auch jeder Anwender, sollte sie optimalerweise verstehen können. Hingegen sollte das Entwicklungsteam tolerant gegenüber der Fachsprache der Anwender sein.

3 Bestandteile einer User Story

Eine User Story setzt sich mindestens aus den folgenden drei Elementen zusammen:

  • Einem kurzen, prägnanten Namen.
  • Einer kurzen Beschreibung der Anforderung.
  • Mehreren Akzeptanzkriterien, die die Details ausdrücken und dokumentieren und bei der Klärung helfen, ob eine Story wirklich abgeschlossen ist.

Nach wie vor hilft diese einfache Satzkonstruktion beim Einstieg in das Schreiben einer User Story:

Um (den folgenden Nutzen zu erhalten), möchte ich als (Anwendertyp) (diese Funktion).

Schauen wir uns die drei Teile dieses Satzes noch einmal etwas genauer an.

Name

Eine kurze, prägnante Benennung, die sich die Teammitglieder und die anderen Beteiligten gut merken können. Am besten ist sie so, dass jeder etwas damit anfangen kann, wenn jemand sagt „Wir sollten noch xy umsetzen“. Wir die Anmeldung an einem System kann also die Bezeichnung „Anmeldung“ ausreichend sein, wenn das Team versteht, was damit gemeint ist.

Beschreibung

Wer möchte eigentlich etwas?

Es ist möglichst klar darzustellen, von wem die Anforderung überhaupt kommt. Vermutlich am häufigsten anzutreffen sind User Stories mit dem Anwendertyp „Benutzer“. Es kann jedoch deutlich spezifischer zum Ausdruck gebraucht werden, um welchen Benutzer es sich handelt. Z.B. durch eine Ergänzung wie „als Benutzer mit einem Twitter-Account“. Das ist schon ein ganzes Stück spezifischer und hilft allen Beteiligten einzuschätzen, wie groß die Nutzergruppe ist und woher ihr Wunsch kommt.
Wenn das Team mit Personas arbeitet, kann es sinnvoll sein, die bestimmte Persona zu nennen, die im besonderen diese Anforderung hegt.

Warum will er das tun, welchen Nutzen will er erzielen?

An dieser Stelle steht der zu Grunde liegende Nutzen, der erreicht werden soll. Die Idee ist dabei, dass die anschließend beschriebene Funktionalität aus dem Nutzenstreben abgeleitet sein muss. Ein Benutzer will sich z.B. nicht als Selbstzweck bei einer Softwareanwendung anmelden, sondern macht diese nur, um die Kernfunktionen der Software anschließend nutzen zu können.

Durch welche Funktionalität will er den Nutzen realisieren?

In diesem Teil wird dargelegt, welche Funktionalität zur Realisierung des Nutzens implementiert werden soll.

Insgesamt könnte die Beschreibung einer User Story damit wie folgt aussehen:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten anmelden).

User Stories können einen sehr unterschiedlichen Grad an Genauigkeit annehmen. Dies hängt auch damit zusammen, wie nah oder weit die Umsetzung der Anforderung ist. Es kann sein, dass die Lösung der User Story noch weitgehend offen gehalten werden soll, oder aber es ist schon eine Entscheidung für eine konkretere Umsetzungsvariante gefallen. Wurde etwa bereits festgelegt, dass in unserer Beispiel-Story die Anmeldung per Twitter-Zugangsdaten mit Hilfe des Protokolls OAuth erfolgen soll, könnte die User Story wie folgt konkretisiert werden:

Um (die Software nutzen zu können), möchte ich mich (als Benutzer mit einem Twitter-Account) (mit meinen Twitter-Zugangsdaten über das sichere Authorisierungsprotokol OAuth anmelden).

Akzeptanzkriterien

Wie kann festgestellt werden, ob die User Story entsprechend den Anforderungen umgesetzt wurde? Die Akzeptanzkriterien spielen dabei eine besondere Rolle. Sie beantworten die Frage, was getestet werden soll. Eine gute Hilfsregel für die Formulierung von Akzeptanzkriterien ist, dass sie mit „Teste…“ anfangen sollten. Beispiele für unsere obige Story könnten sein:

  • Teste die Eingabe eines ungültigen Benutzernamens…
  • Teste die Eingabe eines ungültigen Passworts
  • Teste die Eingabe eines gültigen Benutzernamens und eines gültigen Passworts

Wie stelle ich sicher, dass das Team die User Stories versteht?

Zunächst kann eine gewisse Unsicherheit vorhanden sein, ob das Entwicklungsteam die User Stories in der Form akzeptiert. Hier ist es aber wie mit vielen anderen Dingen in der agilen Softwareentwicklung. Es gehört Mut dazu, Dinge auszuprobieren und sich einzugestehen, dass am Anfang nicht alles rund läuft. Inspect and adapt. Nach ein paar Wochen der Arbeit mit User Stories haben dann alle Beteiligten eine gemeinsame Vorstellung davon entwickelt, wie umfangreich, detailiert und sauber die User Stories ausgearbeitet werden müssen. Das funktioniert am besten, wenn darüber hinaus regelmäßige Backlog Grooming-Sitzungen durchgeführt werden, in denen mit dem Entwicklungsteam und Anwendern zusammen an den Stories gearbeitet wird.

Ergänzende Beschreibungen, Mock-ups, Wireframes,…

Ergänzt werden können diese drei Grundelemente einer User Story durch weitere Informationen, die dem Entwicklungsteam dabei helfen zu verstehen, wie die Umsetzung erfolgen soll. Das können ergänzende Beschreibungen, Mock-ups, Wireframes, Scribbles … you name it … sein. Das wichtigste ist, dass diese das gemeinsame Verständnis der Anforderung unterstützen. Sie sollten aber niemals die persönliche Kommunikation zwischen den Beteiligten ersetzen!

Weiterführende Informationen:

Foto: kmlz

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Werbeanzeigen

QR-Codes zur Aktualisierung von Taskboards – 7 Fragen an Matt Müller


Wer den Raum eines Softwareentwicklungs-Teams betritt, dass sich die Vorteile der agilen Softwareentwicklung zunutze macht, wird in der Regel eines sehen können – ein Taskboard mit Aufgabenbeschreibungen auf Karten, das vom Team zur Organisation der Aufgaben genutzt wird.
Immer wieder sind Besucher bei uns irritiert über diese Rückkehr zu Tafel und Papier, ausgerechnet in einer Softwareschmiede. Viele Teams setzen dabei neben dem Offline-Taskboard zusätzlich auf eine elektronische Aufgabenverwaltung. Die Verwaltung der Aufgaben an einem Taskboard im Teamraum sorgt für eine hohe Transparenz und macht den Arbeitsfluß in einem besonderen Maße sichtbar. Die Verwaltung von Aufgaben in einem elektronischen System hat ebenfalls ihre Vorteile. So lassen sich dort auch große Mengen von Vorgängen dauerhaft für die spätere Bearbeitung vorhalten, einfach mit Links und Grafiken versehen und es kann eine Anbindung an ein Zeiterfassungssystem erfolgen. Die Verwendung von beidem führt jedoch zu einer Herausforderung: Änderungen am Status einer Aufgabe (z.B. „offen“, „in Bearbeitung“, „geschlossen“) müssen in beiden Systemen, digital und analog, erfolgen.

Umso spannender fand ich es, bei meinem ehemaligen Kollegen Matthias Müller von einer selbst entwickelten Lösung für einen einfacheren Abgleich zwischen Taskboard im Teamraum und elektronischer Aufgabenverwaltung zu lesen.
Matthias hat sich bereit erklärt, mir ein paar Fragen zu seiner Lösung zu beantworten.

Matthias, erzähl‘ uns erst einmal wer Du bist und was Du machst.

Hallo Paul! Ich arbeite als Softwareentwickler bei der Rhein Main Multimedia GmbH in Mainz. Wir sind eine Tochtergesellschaft der Verlagsgruppe Rhein Main und somit als Dienstleister hauptsächlich im Umfeld der Onlineangebote unserer Tageszeitungen im Bereich CMS und allen Randgebieten unterwegs. Im Kern der RMM sind wir neben Online Sales und Projektkoordination ein Team von fünf Kollegen, die sich um die Planung und Umsetzung neuer Projekte und Anforderungen an bestehende Systeme kümmern. Im Bereich der agilen Softwareentwicklung sind wir noch Rookies – wir beschäftigen uns seit Anfang des Jahres damit. Dabei machen wir nicht „Scrum by the Book“, weil dies als alleiniges Toolkit für die Vielzahl der von uns betreuten Applikationen nicht als tauglich erschien, sondern bewegen uns in einer gesunden Mischung der unserer Ansicht nach nützlichsten Komponenten aus Scrum und Kanban.

In den letzten Wochen hast Du in Deinem Blog „any-where“ über eine von Dir entwickelte Lösung berichtet, um einen Abgleich zwischen einem Offline-Taskboard und der elektronischen Aufgabenverwaltung mit trac herzustellen. Wie kamst Du auf die Idee und wie funktioniert Deine Lösung?

Hoffentlich hole ich jetzt nicht zu weit aus. Ich arbeite seit 2010 bei RMM und war bis Ende letzten Jahres in ein großes Projekt mit einem unserer spanischen Dienstleister als technischer Berater involviert. Das Projekt scheiterte leider. Wie ich nun weiß, aufgrund der vielen üblichen Fehler, die man machen kann: Falsche Anforderungsanalyse, fehlende Transparenz, das parallele Arbeiten an vielen Tasks und Komponenten, Terminfixierung statt Qualitätsfixierung, fehlende Prioritäten und der Plan eines Big Bang Releases. Erkannt wurde dies früh, aber leider nicht angegangen aufgrund der politischen Struktur des Unternehmens und des Projekts. Anfang des Jahres beschlossen wir, dass dies so nicht mehr passieren darf. Wir begannen, unsere Arbeitsweise hin zu mehr Agilität und Effizienz zu bewegen. Eine Entscheidung übrigens, die direkt aus dem Team heraus angestoßen wurde und einen wirklich spannenden Prozess folgen ließ, der eine merkliche Verbesserung unserer täglichen Organisation und vor allem der Transparenz aller Aufgaben und Projekte mit sich brachte. Ich will das gar nicht im Detail ausführen. Aber unter anderem hängt in unserem 4-Mann-Büro nun ein großes Taskboard, das über alle Projekte hinweg unsere Tasks erfasst und jeden Morgen in einem Daily Stand-up besprochen wird. Auf der Suche nach einem OpenSource-Tool für agile Entwicklung stieß ich auf Agilo als (recht) brauchbare Erweiterung für Trac. Dieses setzen wir nun ein und brauchten quasi sofort eine einfache Möglichkeit, das Offline-Medium Board mit dem Online-Medium Agilo zu verheiraten. Agilo und Trac bringen von Hause aus keine Unterstützung mit. Deshalb entwickelte ich ein kleines Java-Tool TracPrinter, welches aus einem Applet heraus das Drucken von Task-Cards erlaubt. Mit diesem schafften wir den Weg in die eine Richtung: Aus dem Intranet ans Board.

Nun kommt es bei uns oft vor, dass ein Ticket bearbeitet wurde, in „Done“ auf dem Board verschoben, aber in Agilo nicht aktualisiert wurde. Das ist ärgerlich, weil es neben dem Aufwand des nachträglichen Änderns in Agilo viele zu beantwortende Nachfragen gab, wenn die Tickets in Agilo kontrolliert wurden. Wir brauchten also einen einfachen Weg, Tickets in Agilo schnell schließen zu können. Da quasi jeder Zugang zu einem iPhone oder Android-Gerät mit WI-FI-Zugang zum Intranet hat, dachte ich, dass es das einfachste wäre, über das Smartphone eine Möglichkeit zu schaffen, Tickets in Agilo zu bearbeiten. Als einfachste Lösung schienen hier QR-Codes in Frage zu kommen: Somit wurde TracPrinter erweitert um eine Funktion, welche QR-Codes mit einem hinterlegten internen Link zu einem einfachen PHP-Script auf die Ticket-Karten schließt. Nach Scannen des QR-Codes öffnet der Browser dieses Script auf dem Server im Intranet. Derzeit schließt dieses wirklich nur „hart“ das Ticket. So haben wir erreicht, dass Tickets direkt nach Fertigstellung oder im Daily Stand-Up innerhalb von Sekunden geschlossen werden können.

Wie bewährt sich diese Lösung bei Euch im Praxis-Einsatz?
Die Gesamtlösung mit TracPrinter und der neuen QR-Code-Lösung unterstützt unsere Prozesse recht gut. Wie bei allen Dingen steht und fällt dies natürlich mit der Gewohnheit der User: Man muss natürlich dran denken, den TracPrinter zu nutzen, um ein Ticket, das man gerade erstellt hat, auch ans Board zu bekommen. Hier kommen wir öfter an den Punkt, dass ein Ticket zwar in Agilo ist, aber nicht am Task-Board hängt. Aber wir werden besser. Das korrekte Schließen des Tickets in Agilo wird im Daily Stand-Up mittlerweile abgefragt und im Zweifel direkt per Smartphone geschlossen. Hier haben wir wirklich einen Gewinn.

Welche weiteren Entwicklungspotenziale siehst Du für Deine Lösung?
Noch ist alles eine Sammlung loser Tools: Agilo hat seine eigene URL, der TracPrinter ist unter einer eigenen URL im Intranet erreichbar, ebenso das Script, welches Requests via QR-Codes entgegennimmt. Das klappt natürlich – geplant ist allerdings, alles zusammen in eine Erweiterung für Trac zu überführen, um alles an einer Stelle zu haben und den manuellen Schritt des Druckens von Karten direkt in die Erzeugung von Tickets zu integrieren. Darüber hinaus habe ich ja erwähnt, dass via QR-Code die Tickets hart geschlossen werden: Man kann noch nicht differenzieren, ob ein Ticket done oder invalid ist. Auch eine Schnittstelle zur Kommentarfunktion von Agilo existiert nicht. Da die Lösung aber gut angenommen wird, ist der Plan, ein mobiles Interface für Agilo zu schaffen, das es erlaubt, direkt alle Informationen über ein Ticket abzurufen und eine Möglichkeit zu schaffen, den verschiedenen „Schließmöglichkeiten“ in Agilo gerecht zu werden. Somit kann man noch mehr Zeit vor dem Board statt vor Agilo im Notebook verbringen 🙂 Das wird die Kommunikation über Tickets bestimmt weiter fördern.

Ein dänisches Scrum-Team von Vodafone hat vor einigen Monaten eine Lösung für den Abgleich zwischen JIRA und einem Offline-Taskboard mittels RFID-Technologie vorgestellt und dafür einige Aufmerksamkeit bekommen. Wie siehst Du die QR-Lösung im Vergleich zu einer RFID-Lösung? Was hat mehr Potenzial für die Zukunft?

Ja, die RFID-Lösung ist sehr fancy. Vor allem das automatische Einblenden des Burndown-Charts ist spektakulär und wirklich motivierend! Man sieht in Echtzeit den Effekt der Abarbeitung des eigenen Tickets. Tatsächlich war das Video, das ich im Dezember in Deinem Blog über diese Lösung gesehen habe, durchaus ein Impulsgeber für die Ideen, die hier mit Trac und QR-Codes nun umgesetzt sind. Das Problem, Onlinetools mit Offlinemedien zu synchronisieren, ist im Bereich der agilen Entwicklung sicher an vielen Stellen aktuell. Die Entscheidung, Papier zu nutzen und nicht auf einen „großen Touchscreen“ als digitales Board zurückzugreifen und alles direkt online abzubilden, wird ja bewusst getroffen. Nun sind QR-Codes sehr billig, RFID aber leider nicht. Das ist sicher auch einer der Gründe, weshalb wir auf QR-Codes setzen 🙂 Ich weiß ehrlich gesagt nicht, ob und welche Möglichkeiten es bereits mit QR-Codes für marktführende Tools wie Jira gibt. Ich kann mir aber durchaus vorstellen, dass dies eine tolle Unterstützung für viele Projekte sein kann. Uns nutzt es sehr – und solange nicht jeder die Möglichkeit hat, einen RFID-Scanner hinter sein Board zu hängen, ist dies sicher die effizientere Variante. Wenn das Vodafone-Modell aber in Serie geht, werde ich hier sicher vorschlagen, das zu kaufen 🙂

Wie siehst Du in Zukunft die Entwicklung zwischen elektronischem Taskmanagement und Taskboards in Teamräumen. Was für Möglichkeiten werden sich uns da in den nächsten 5-10 Jahren bieten?

Es dauert sicher nicht lang, bis der erste Anbieter ein elektronisches Hardware-Board für den kommerziellen Vertrieb bereitstellt. Auf welcher Technologie dies basiert, sei mal offen gelassen. Aber ich kann mir sehr gut vorstellen, dass es sehr interessante Lösungen geben wird, die in Richtung der Vodafone-Version gehen werden. Das Problem hier ist m.E. nicht unbedingt die technische Machbarkeit und die Kosten sondern vielmehr die Vielzahl der Produkte im Bereich „Taskmanagement“ und die Eigenarten der agilen Arbeit in Organisationen. Dem gerecht zu werden ist sicher eine Herausforderung für Hersteller. Am Ende ist ein einfaches Whiteboard doch schneller den persönlichen Bedingungen angepasst. Natürlich könnte ein Anbieter speziell für die Schnittstelle zu Jira (oder warum auch nicht Agilo/Trac?) ein solches Board herstellen. Ich bin selbst gespannt, was hier kommen wird. Ob RFID hier eine Lösung ist oder tatsächlich mit QR-Codes gearbeitet wird, die von einem Scanner direkt im Board verarbeitet werden können, ist sicher eine Frage der Kosten. Papier ist billiger als RFID. Aber wer weiß, wie sich das entwickelt.

Zum Schluss noch einmal zum Thema QR-Codes: Werden diese dauerhaft interessant und vielfältig im Einsatz sein oder stellen sie nur einen Übergang zu neuen Technologien und Lösungen dar?

Für mich ist unsere QR-Lösung tatsächlich der erste Fall, wo ich – jenseits von logistischen oder produktionstechnischen Anwendungsfällen – einen persönlichen professionellen Nutzen in QR-Codes sehe. Jetzt nutze ich sie täglich als Unterstützung meiner täglichen Arbeit 🙂 Im Consumerbereich sieht das anders aus: Für Endanwender sind QR-Codes ja schon heute bspw. für Ticketing oder Check-ins vielfältig im Gebrauch. Ihr Gebrauch ist einfach und kostengünstig. Wir arbeiten hier auch an Projekten, in denen QR-Codes im Bereich des Couponings und Location Based Services eine Rolle spielen werden. Somit werden sie uns noch eine Weile begleiten 🙂

Vielen Dank, Matthias!
Sehr gerne!

So sehen die Printouts mit QR-Code dann aus:
QR-Codes zur einfachen Aktualisierung eines Taskboards (Foto: Matthias Müller)

Blogartikel von Matthias Müller zu seinen Erweiterungen für trac:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Die besten Ressourcen zu User Stories

Userstories sind eine besondere Form der Anforderungsbeschreibung, die sowohl Kunden, Anwender, Projektmanager als auch Softwareentwickler verstehen können. Besonders gerne werden sie in der agilen Softwareentwicklung eingesetzt. Dieser Beitrag gibt einen Überblick über die besten Artikel und Bücher zum Thema User Stories:

Deutschsprachige Artikel

Englischsprachige Artikel

Buchtipps:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Englische Version des Artikels

Produktmanagement Lesetipps: Anforderungsmanagement, Scrum ProductMaster, Nutzenorientierung, Scrum und Kanban, JIRA mit Plugin Greenhopper

Die aktuellen Lesetipps rund um Produktmanagement und agile Softwareentwicklung:

  • In einem sehr lesenswerten Beitrag schreibt Tom Grant im Blog von Forrester, was Anforderungsmanagement mit dem Beruf eines Journalisten gemeinsam hat: Why Requirements Are Like Journalism.
  • Warum kann ein Scrum Product Owner nicht zugleich die Rolle des ScrumMasters übernehmen? Einen Artikel dazu mit reichlich Diskussionen hat Vikas Hazrati geschrieben: Scrum Does Not Have a ProductMaster Role.
  • Chris Sterling schlägt einen 5-stufigen Prozess vor, mit dem die Fokussierung auf den Nutzen für die Anwender sichergestellt werden soll. Für jeden Product Owner ein absoluter Lesetipp: Focus on Value.
  • Matthias Mueller hat in seinem Blog eine Reihe interessanter Artikel zu Scrum und Kanban zusammengetragen.
  • Bei der Einführung neuer Vorgehensmodelle und Methoden kommt häufig auch die Frage auf, inwieweit Tools die Arbeit unterstützen können. Wie die Software JIRA zusammen mit dem Plugin Greenhopper dabei helfen kann, agile Projekte digital abzubilden, zeigt dieser Artikel samt Video.
Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Produktmanagement Lesetipps: Definition of Ready, Geschäftsmodelle validieren, „Running Lean“ zum kostenlosen Download

Die Weihnachtstage liegen hinter uns und es geht mit großen Schritten auf das neue Jahr zu. Dennoch bleibt mein RSS-Reader mit zahlreichen interessanten Blogs zum Produktmanagement und zu agiler Softwareentwicklung auch in dieser Zeit nicht leer. Ein paar besonders interessante Posts möchte ich gerne mit euch teilen.

Roman Pichler muss gewusst haben, was uns derzeit umtreibt. Gerade, wo ich mit meinem Team über eine Definition of Ready gesprochen habe, also eine Festlegung, wann eine User Story und andere Aufgaben bereit für eine Umsetzung sind, veröffentlicht er einen Blogpost über The Definition of Ready. Vielen Dank dafür! 😉 Der Artikel wird in Kürze unseren Teamraum zieren.

Jason Cohen ist ein Großer. Vor einigen Jahren hat er SmartBear Software, ein Unternehmen, das Tools für die Softwareentwicklung und für Softwaretests entwickelt, aufgebaut und verkauft. In der Zwischenzeit hat er sich weiteren Projekten gewidmet und baut derzeit WPEngine auf. Zufällig kommt er auch noch aus einer meiner Lieblingsstädte in den USA, Austin. Jason schreibt ein hervorragendes Blog, dass jedem Produktmanager wärmstens zu empfehlen ist: A Smart Bear. Ein Teil seiner Blogposts wird zusätzlich bei Building43 veröffentlicht, ein Blog, das kein geringerer als Robert Scoble verantwortet. Vor kurzem ist wieder ein sehr wertvoller Artikel erschienen, in dem Jason empfiehlt, mindestens 10 Leute zu suchen, die die bestätigen, dass sie dein Produkt kaufen würden, bevor du mit dessen Umsetzung startest: Yes, but who said they’d actually BUY the damn thing?

Ebenfalls aus Austin kommt Ash Maurya. Er schreibt ein Blog über Lean Startups. Eine erste Version eines Buches, das er bald unter dem Namen „Running Lean“ veröffentlichen möchte, hat er jetzt für seine Leser kostenlos zum Download bereitstellt: Grab your copy of “Running Lean” (roughcut).

Dir hat dieser Beitrag gefallen? Dann hinterlasse doch einen Kommentar. Wenn du über das Produktmanagement und die Vermarktung von Internetanwendungen auf dem Laufenden gehalten werden möchtest, kannst du auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Card, Conversation, Confirmation: Die drei C’s einer User Story

Was gibt es bei der Erstellung von User Stories zu beachten? Drei C’s können dabei helfen: Card, Conversation, Confirmation. Die drei C’s gehen auf Ron Jeffries zurück, der sie schon 2001 in einem Blogpost beschrieb: Essential XP: Card, Conversation, Confirmation.
Noch heute gelten sie neben den INVEST-Kriterien als wichtige Grundregel bei der Erstellung von User Stories.

Card
User Stories sollen kurz und prägnant sein. Sie sollen in erster Linie an den Kundenwunsch erinnern und die wichtigsten Punkte, die mit dem Team vereinbart wurden, festhalten. Viele agile Software-Entwicklungsteams verwalten Stories und Tasks offline, z.B. in Form eines Taskboards. Die Kundenwünsche werden dann auf Karteikarten festgehalten. Es sollte damit nicht mehr Platz als der auf der Karte verfügbare benötigt werden, um dem Team klarzumachen, was mit der Umsetzung der Story erreicht werden soll. Reicht der Platz nicht aus, ist die Story in der Regel zu groß oder wird zu umfangreich dokumentiert. Über die Card hinaus werden Informationen über den Wunsch in Form der Konversation mit dem Team abgestimmt.

Conversation
Jede Story wird zwischen dem Kunden und dem Team mindestens einmal besprochen. Der Austausch über die Story wird als sehr wichtig erachtet. Es reicht nicht, auf einer Karte die Anforderungen festzuhalten und dem Team „durch einen Türschlitz“ zuzuschieben. Stories werden in der Regel sogar mehrmals besprochen, z.B. während einem Anforderungsworkshop, in einer Schätzklausur und während der Sprint-Planung. Die mündlichen Absprachen werden manchmal begleitet durch zusätzliche Dokumente, wie etwa Vorlagen in einem Projektwiki oder Mockups.

Confirmation
Um einen Nachweis zu haben, ob die Stories in der gewünschten Form implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Der Kunde hält dafür vor Beginn der Umsetzung einer Story die zentralen Kriterien fest, nach denen die Abnahme der Story später erfolgen soll. Durch die Implementierung von Akzeptanztests kann die Erfüllung der Akzeptanzkriterien sichergestellt werden.

Mit den drei C hat uns Ron Jeffries eine gute Merkhilfe für die Grundregeln einer User Story an die Hand gegeben.

Weitere gute Lektüre zu User Stories:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von jakuza

User Stories: Anforderungen aus Nutzersicht dokumentieren

User Stories Für das Blog von //SEIBERT/MEDIA habe ich einen Artikel über User Stories geschrieben: User Stories: Anforderungen aus Nutzersicht dokumentieren.
Der Artikel erklärt, warum User Stories als Werkzeug zur Beschreibung von Anforderungen sinnvoll sind, mit welchem Gerüst sich User Stories einfach schreiben lassen, welche Kriterien eine gute User Story erfüllen muss und auch, was eine Story Card ist.

Zum Artikel im //SEIBERT/MEDIA Blog

 

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von psd

User Stories schreiben ist wie Fahrrad fahren


Schon einmal versucht, jemandem zu erklären, wie man Fahrrad fährt? Macht nicht wirklich Sinn, oder? Man muss einfach üben, üben, hinfallen, weiter üben.

So ähnlich ist das auch mit dem Schreiben von User Stories. Diese Form der Anforderungsbeschreibung lässt sich natürlich grundlegend auch rein verbal erklären. Eine User Story besteht aus einem Namen, einem beschreibenden Satz und einer Reihe von Akzeptanzkriterien. Aber gute Stories schreiben lernt man nicht durch eine Erklärung. Das ist genau so ein Balanceakt wie Fahrrad fahren. Die Stories sollen weder zu ungenau, noch zu detailliert, weder zu groß, noch zu klein sein. Übung im Schreiben von User Stories an sich und der Austausch mit dem Team ist dabei unerlässlich. Das Team wird in der Regel sehr deutlich kommunizieren, welcher Detaillierungsgrad einer Story ausreichend ist und insbesondere, wenn er es einmal nicht ist. Ein Anforderungsworkshop mit dem gesamten Team zum Start des Projektes kann helfen, sich aufeinander einzuspielen.

Im Laufe des Projekts entwickelt sich eine gemeinsame Sprache zwischen den Beteiligten, die zu einer Vereinfachung der Zusammenarbeit führt und es damit gerade auch jenen leichter macht, die in dem Projekt einen großen Teil der Stories schreiben.

Aber am Anfang steht: der Anfang. Wie beim Fahrrad fahren. Der Mut wird belohnt.

Weitere Informationen zu User Stories:

Foto: Von Bruce McAdam

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

%d Bloggern gefällt das: