Investiere in gute User Stories

Home » Blog » Scrum » Investiere in gute User Stories
  • Investiere in gute User Stories

Investiere in gute User Stories

Eine der wichtigsten Merkformeln im Umfeld von Scrum lautet: Investiere in gute User Stories. Aber was macht eigentlich eine gute User Story aus und worauf sollte man achten? Heute möchte ich ein wenig Klarheit in die sogenannte INVEST-Formel bringen. Wenn Du Dich als Product Owner gemeinsam mit Deinem Entwicklerteam an dieser Formel orientierst, wird die Wahrscheinlichkeit, das gemeinsame Sprintziel zu erreichen, deutlich steigen.

Eine gute User Story sollte das Akronym INVEST beachten: Sie ist independent (unabhängig), negotiable (verhandelbar), valuable (wertvoll), estimatable (schätzbar), short (kurz genug für einen Sprint) und testable (überprüfbar). Wenn Du diese Grundsätze beachtest, kannst Du potenziellen Ärger während eines Sprints deutlich reduzieren. Die INVEST-Formel ist außerdem eine gute Orientierung, wenn ein Scrum Team eine sogenannte Definition of Ready entwerfen möchte. (Die Definition of Ready wird allerdings nirgends im Scrum Guide erwähnt und ist nicht zwingend notwendig. Allerdings ist sie für viele Scrum Teams ein große Hilfe und wird sehr häufig verwendet.)

Independent

Unabhängigkeit ist – meiner Meinung nach – eine der wichtigsten Aspekte einer guten User Story. Und damit sind sowohl interne Abhängigkeiten (zu anderen User Stories) gemeint, als auch externe Abhängigkeiten zu anderen Abteilungen, Kunden, Lieferanten etc. Je unabhängiger Deine User Story ist, desto besser kann Dein Scrum Team das Sprintziel aus eigener Kraft erreichen. Je mehr bekannte Abhängigkeiten existieren, desto eher wird das Entwicklerteam zum Spielball von Einflüssen, die es selbst nicht auflösen kann.

Versuche immer, die User Story so zu gestalten, dass Abhängigkeiten zu anderen User Stories eliminiert werden. Wenn sich Abhängigkeiten zu anderen User Stories nicht vermeiden lassen, lohnt es sich, darüber nachzudenken, beide User Stories gleichzeitig mit in den Sprint zu übernehmen. Es ist auch denkbar, eine User Story, bei der Abhängigkeiten existieren, so „umzuschneiden“, dass nur die Teile einer User Story in den Sprint übernommen werden, die unabhängig sind.

Existieren externe Abhängigkeiten, so kann es durchaus sinnvoll sein, diese User Story nicht mit den Sprint zu übernehmen, bis diese Abhängigkeit aufgelöst ist. Hier musst Du allerdings besonders aufpassen, denn durch dieses Vorgehen kann schnell Wasserfall-Denken entstehen: „Bevor wir nicht die Zusage vom Lieferanten haben, fangen wir gar nicht erst mit der Arbeit an.“ Solange ein Scrum Team aber genügend andere (gleichermaßen wichtige) Aufgaben hat, die solche Abhängigkeiten nicht haben, ist es – meiner Meinung nach – legitim, diese vorzuziehen.

Externe Abhängigkeiten sind in der Regel Impediments und es ist die Aufgabe des Scrum Masters, diese aufzulösen. Wenn also externe Abhängigkeiten existieren, darf Dein Scrum Team nicht einfach warten, bis sich die Probleme in Luft auflösen, sondern muss aktiv daran arbeiten, diese Abhängigkeiten aufzulösen. (Auch die Entwickler können eine (neue) User Story in ihren Sprint übernehmen, die externe Abhängigkeiten reduziert.)

Negotiable

Jede User Story sollte außerdem verhandelbar sein. Das bedeutet, dass User Stories keine kleinteiligen Aufträge und Vorgaben sind, sondern dem Entwicklerteam Spielraum bei der Umsetzung bieten. Kunden und Stakeholder geben mit einer User Story zwar vor, was sie benötigen und warum sie eine bestimmte Funktion brauchen, legen aber nicht fest, wie die Lösung genau auszusehen hat. Die meisten Scrum Teams, die ich kenne, verwenden für ihre User Stories diese Formel:

Ich als  möchte <Funktion/Ziel>, sodass ich <Grund/Zweck> erreichen kann.

Dadurch wird zwar beschrieben, was jemand benötigt und warum es notwendig ist, aber es werden keine strengen Vorgaben dabei gemacht, wie das Ganze zu verwirklichen ist. Wenn ich sage: „Ich als Kunde Eures Streaming-Dienstes möchte über neue Musik meiner Lieblingsinterpreten informiert werden, damit ich keine Neuigkeiten verpasse“, ist das etwas ganz anderes als wenn ich sage: „Hier an genau dieser Stelle muss ein grüner Button für den E-Mail-Newsletter angezeigt werden, der einmal in der Woche verschickt wird.“

Valuable

User Stories müssen wertvoll sein. Damit wird sichergestellt, dass ein Scrum Team nur das entwickelt, was auch den Wert des Produktes steigert und keine Zeit für Funktionen verschwendet wird, die niemand braucht. Hier ist ganz besonders der Product Owner gefragt! Nur er entscheidet, welches diejenigen User Stories sind, die im Product Backlog ganz weit oben stehen. User Stories, die keinen Wert für den Kunden haben, kommen gar nicht erst in das Backlog hinein.

Estimatable

Eine User Story muss schätzbar sein. Es musst klar sein, wieviel Aufwand es sein wird, diese User Story zum Leben zu erwecken. Diese Aufwandsschätzung einer User Story geschieht im sogenannten Refinement. Hier diskutieren Entwickler und Product Owner darüber, wie es möglich sein kann, die User Story umzusetzen. Dadurch wird sich im Verlauf des Dialogs herauskristallisieren, was denkbare Wege sind, die Story umzusetzen. Und wieviel Aufwand das sein wird. Viele Scrum Teams nutzen hierzu auch das sogenannte Planning Poker, um das Gespräch zu steuern und fruchtbar zu machen.

Short

Eine gute User Story sollte außerdem kurz sein. Und zwar vor allem kurz genug für einen einzigen Sprint. Der Grundgedanke von Scrum ist es ja, zum Sprintende in der Review ein fertiges Inkrement präsentieren zu können. Wenn wir uns mit Dingen beschäftigen würden, die länger als einen Sprint dauern, führen wir diese Grundidee von Scrum ad absurdum.

Natürlich gibt es große Anforderungen, die länger als einen Sprint dauern. Aber jede noch so große Anforderung lässt sich in zwei oder mehrere Teile zerlegen, die wir in einem Sprint realisieren können. Wir müssen lediglich darauf achten, dass jeder dieser einzelnen Teile noch immer eine neue Funktion für unsere Kunden liefert.

Testable

Zu guter Letzt muss eine User Story testbar sein. Das heißt, wir wissen so exakt wie möglich, wann wir fertig sind mit der User Story. Im günstigsten Fall ist das eine Prüfung, die uns entwder „Ja“ oder „Nein“ als Ergebnis ausliefert. Und neben den klaren Kriterien darüber, ob wir eine User Story realisiert haben, haben wir natürlich auch ein Prüfverfahren, das uns dieses Ergebnis liefern kann. Uns reichen also nicht nur klare Kriterien, sondern wir benötigen auch ein Verfahren, das diese Kriterien überprüft.

Mehr Infos

Scrum & Agiles Projektmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deiner Abteilung einführen, weißt aber nicht wie Du vorgehen sollst? Ich berate Dich gerne!

Mehr Infos
Von |2018-10-21T15:29:57+00:0021. Oktober 2018|Kategorien: Scrum|Schlagworte: , |0 Kommentare

Über den Autoren:

Ich glaube an eine Arbeitswelt, in der Menschen darauf brennen, am Montag endlich wieder zur Arbeit gehen zu dürfen. Deshalb helfe ich Menschen, Unternehmen und Organisationen, Arbeitsumgebungen so zu gestalten, dass sich Motivation und Engagement entfalten können.

Hinterlasse einen Kommentar

Newsletter

Diese Website benutzt Cookies und anderes Teufelswerk. Näheres dazu findest Du auf unserer Datenschutz-Seite. Verwalte hier Deine Einstellungen Einverstanden

Angebote von Drittanbietern

Hier kannst Du auswählen, welche Angebote von Drittanbietern Du während Deines Besuches auf dieser Webseite erlauben möchtest und welche nicht.