User Story Training für Scrum Master

Auch erfahrene Scrum Master stoßen bei dem Thema User-Storys häufig auf taube Developer!

Beim User Story Training und in meinen Seminaren treffe ich regelmäßig auf gleichermaßen erfahrene wie verzweifelte Scrum Master. Der Grund der Verzweiflung ist dabei fast immer der gleiche:

Als [Scrum Master] muss ich [dem Scrum Team den sicheren Umgang mit User Storys vermitteln], um [bessere Produkte und zufriedenere Kunden zu erhalten]

Du als Scrum Master bist für die Struktur und das Management der Entwicklung verantwortlich. An zähe Auseinandersetzungen und sich wiederholende Diskussionen hast du dich längst gewöhnt. Vor allem die Dev-Teams und Product Owner geraten immer wieder aneinander. Inhalte, Schätzungen und vermeintlich unvollständige User-Storys werden zum Streitpunkt:

  • Die Formulierungen der User-Storys unterstützen nicht die Vorstellungskraft der agilen Developer
  • Die Fülle an Details in den User-Storys unterbinden jegliche Kreativität und Individualität
  • Das User Story Mapping fällt aus zeitlichen Gründen aus.
  • Das Story-Splitting wird nicht ideal durchgeführt.
  • Die Sicht des Kunden bleibt unberücksichtigt.

Viele Scrum Master unterschätzen ihren Verantwortungsbereich. Sie wissen nicht, welchen Einfluss ihr Handeln auf den Prozess ausübt!

User Story Training mit Scrum und Zertifizierung

Als Scrum Master ist es deine Verantwortung, das Development Team zu unterstützen, zu motivieren und Hindernisse aus dem Weg zu räumen. Du unterstützt den Product Owner dabei, sein Backlog effizient und priorisiert zu pflegen.

Am Ende des Tages wollen alle das gleiche: die Entwicklung eures Produktes erfolgreich abschließen.

Das hört sich zunächst nach grauer Theorie an. Alles Aussagen, die dir schon längst bekannt sind. Bitte lass mich dir kurz erklären, worauf ich eigentlich hinaus möchte.

Schauen wir uns doch mal eine typische Situation in Scrum an:

1. Der Product Owner hat eine Vorstellung davon, was er umsetzen möchte. In der
Regel hat ein Product Owner wenig oder zu viel technisches Knowhow.
2. Agile Developer sind Fachleute, die ihr Handwerk professionell beherrschen.
3. Je nach Fokus des Product Owner sind die User Storys mit zu viel oder zu wenig
Details angereichert. In beiden Fällen wird eine Diskussion über die User Story bereits im Keim erstickt.

4. Zur Behebung der Probleme beginnen die Developer damit, eigene User-Storys zu
entwerfen. Oder sie passen bestehende User-Storys an. Diese User-Storys sind naturgemäß aus der Sicht der Developer geschrieben und dadurch oft sehr technisch und detailliert.
5. Der Anwender/Kunde wird nicht mehr berücksichtigt.

„Was kann ich als Scrum Master dagegen tun?“

Ganz einfach: Lerne die richtigen Methoden, wie bessere User-Storys geschrieben werden.
Dann gibst du dieses Wissen weiter. Denn du bist Scrum Master.
Begreife das “Master” nicht als „Meister“ – sondern als deine Aufgabe. Nämlich als die Aufgabe, sämtliche notwendigen Techniken zu beherrschen, die ein Team erfolgreicher machen! Wenn dein Team User-Storys effizient splittet, bei Schätzungen Punktlandungen hinlegt und mit den richtigen Akzeptanzkriterien den Anwender in den Mittelpunkt stellt, hast du deine Aufgabe meisterlich erfüllt.

All das gilt auch für die von Scrum nicht definierte Anwendung von User-Storys, wenn das
Team User-Storys verwenden möchte! Zeige den Scrum-Teams die einfache und
wirkungsvolle Anwendung von User-Storys. Fördere die Kommunikation im Team nach den 3C von Ron Jeffries:

Card – Conversation – Commitment

Bringe mit deinem Team User-Storys kurz und prägnant auf den Punkt. Tauscht euch konstruktiv über die User-Storys aus. Und definiert zentrale Akzeptanzkriterien.

User Story Card

Eine User-Story braucht nicht viele Worte. Im Gegenteil: Eine funktionierende User-Story passt immer auf eine Karteikarte! Wer möchte was und warum? That’s all. Reduziert Informationen, die auf der Karte landen, auf das Wesentliche. Mit dem vorhandenen Platz auf der Karte haltet ihr die wichtigsten Punkte fest. Ihr erinnert an den Bedarf des Anwenders. Vor allem macht ihr mit der Karte klar, was genau mit der User-Story erreicht werden soll. Die Karteikarte ist ein hervorragendes Messmittel. Genügt euch der Platz auf der Karteikarte nicht, ist die User Story zu groß. Oder zu detailliert dokumentiert.

Conversion

Eine User-Story ist es wert, dass man über sie spricht. Der regelmäßige Austausch mit allen Stakeholdern eines Projekts liefert Updates zum Projektverlauf und bringt verschiedene Meinungen, Gedanken und Gefühle auf den Tisch. Ein häufiger Fehler in agilen Teams ist es, dass User-Storys auf Karten festgehalten werden – diese aber dann dem Dev-Team ohne weiteren Austausch zum Abarbeiten „auf den Tisch gelegt“ werden. Nope, das wird nicht funktionieren! Vielmehr laden User- Stories dazu ein, mehrmals im Verlauf eines Projekts besprochen zu werden! Nutzt diese Einladung!

Commitment

Akzeptanzkriterien sind zentraler Bestandteil einer User-Story. Akzeptanzkriterien sollten durch den Anwender definiert werden, bevor die eigentliche Entwicklung des Produktes beginnt. Sie stellen die „Spielregeln“ dar, die von deinem Team eingehalten werden müssen, um eine User Story erfolgreich zu beenden. Mit den Verpflichtungen wird die Kreativität deines Teams in die richtige Bahn gelenkt. Schaffe den Raum für bessere Produkte und zufriedene Kunden.

Fazit

Gute User-Storys schreiben ist allerdings nur eine Seite der Medaille. Die Schätzung einer User-Story, die andere Seite – und eine weitere Herausforderung, die du als Scrum Master meistern musst. Damit User-Storys nicht falsch verstanden, aber dafür punktgenau geschätzt werden, benötigst du die richtige Methodik und das passende Training und das Wissen, wie du deinem Team den Umgang mit User-Storys erklärst. In meinem User Story Training gebe ich dir die passenden Werkzeuge mit auf den Weg, um dein Team zu motivieren und Hindernisse meisterhaft aus dem Weg zu räumen.

Lerne, bessere User Storys zu schreiben!

Wir sehen uns.

 

Frank Schatz,
damit es agil wird.

Ich wünsche dir eine stressfreie Zeit.
Frank

Frank Schatz

Frank Schatz

Als Trainer, Mentor und Coach ist Frank Schatz vielleicht einer der gefragtesten T-Shaped Agilisten im deutschsprachigen Raum. Er ist geprüfter Sachverständiger für agiles Projektmanagement und seit über 25 Jahren IT-Unternehmer, Agile Work Experte und Certified Instructor. Frank Schatz, damit es agil wird.

Agile Work

Die Agile Transformation

Agiles Mentoring