In nahezu jedem agilen Produktentwicklungs-Projekt stellt sich die Frage: wie kommen wir von der Produkt Vision zum Produkt Backlog? Aus diesem Anlass haben wir das nachfolgende Schaubild entwickelt.

In dem Beitrag beschreiben wir, was wir unter einem Product Vision Board verstehen, was ein Use Case Modell ist, was wir unter User Stories und dem Produkt Backlog verstehen. Ausserdem beschreiben wir den Unterschied zwischen Use Cases und User Stories und warum beide eine Berechtigung haben.

 

Was ist das Produkt Vision Board?

Dieses Board beschreibt die übergreifende Vision, die das Produkt leitet. Es listet auf, wer das Produkt verwenden und kaufen sollte (Zielgruppe), warum Menschen es benutzen und kaufen sollten (Bedürfnisse), welche die wichtigsten Funktionen des Produkts sind (Produkt) und warum die Organisation Geld in dieses Produkt investieren sollte (Geschäftsziele). Dabei ist es wichtig, zu verstehen, dass das Vision Board den Innovations- und Produktentwicklungsprozess in Gang setzen soll. Es soll nicht die Nutzer, das Produkt und das Geschäftsmodell umfassend oder besonders detailliert beschreiben. Vielmehr hält es die entscheidenden Annahmen fest.

(Danke Roman Pichler!)

 

Was ist ein Use Case Diagramm?

Ein Use-Case-Diagramm (dt. Anwendungsfall-Diagramm) zeigt das externe Verhalten eines Systems aus der Sicht der Nutzer, indem es die Nutzer (im UML-Jargon „Akteure“ genannt), die Use-Cases und deren Beziehungen zueinander darstellt. Ein Nutzer kann eine Person, aber auch ein Nachbarsystem sein.

Was sind User Stories?

Eine User Story erzählt eine kurze Geschichte aus der Sicht des Anwenders, um eine gewünschte Funktionalität an das System zu beschreiben. Für diesen Zweck konzentrieren Sie sich nur auf das Was und schreiben Ihre Geschichte in einfacher Sprache, damit sie alle Beteiligten ohne technischen Hintergrund verstehen können. Denn die User Story soll die Brücke zwischen Entwicklung und Kunden bilden.

Wie genau Sie die Funktionalität umsetzen, ist für eine User Story unerheblich. Eine User Story ist außerdem flexibel und passt sich neuen Erkenntnissen an: Sie lässt sich somit erst grob erfassen und mit mehr und mehr Details füllen, bis sie detailliert genug ist, um sie umzusetzen. Ziel einer User Story ist es immer, einen Mehrwert für den Kunden zu schaffen.Eine User Story kann mehrere technische Tasks haben.

 

Unterschied zwischen User Story und Use Case

Wenn Sie agil arbeiten, dann setzen Sie auch häufig sogenannte Use Cases ein: Sie beschreiben, wie Anwender (Akteure) mit dem zu entwickelnden System interagieren. Use Cases sind sehr beliebt, da sie wie auch User Storys eine Grundlage bilden, um Anforderungen an das Produkt zu finden. Außerdem ist ihr Ziel ebenfalls, dem Anwender bzw. Stakeholder Mehrwert zu schaffen. Worin also unterscheiden sich Use Cases von User Storys? Use Cases sind sehr umfangreich, weil sie Informationen zum gesamten Kontext bieten. Sie sind langlebig und werden während des gesamten Projekts gepflegt, während User Storys häufig nur eine Iteration lang „überleben“. Eignet sich dann das eine Hilfsmittel mehr als das andere oder schließen sie sich beide gar aus? Die Antwort lautet: Nein, Use Cases und User Storys schaffen nur unterschiedliche Perspektiven auf das System und ergänzen sich sehr gut. Daher lohnt es sich, beide Werkzeuge zusammen für Ihre Projekte einzusetzen. Zum Beispiel eignen sich User Storys, um Szenarien von Use Cases zu verstehen und abzubilden. Durch die Kombination beider Methoden können Sie Ihre Anforderungen leichter und genauer definieren.

Was ist ein Product Backlog?

Das Product Backlog (manchmal auch als Domäne Backlog bezeichnet: immer dann, wenn es pro Domäne ein Backlog gibt) ist der Kern eines Scrum-Projekts, denn es sammelt Anforderungen, die das Produkt erfüllen muss. Das können zum Beispiel Funktionalitäten sein, die das Team implementieren bzw. beheben soll. Meistens bedient man sich sogenannter User Stories, um sie zu beschreiben. Das heißt zum Beispiel, dass eine neue Funktionalität aus der Sicht der Zielgruppe definiert wird:

„Als Besucher der Website möchte ich eine Suchfunktion nutzen können, mit der ich die gesamte Seite durchsuchen kann, damit ich schnell Antworten auf meine Fragen finde.“

Doch nicht alle Anforderungen sind gleich wichtig oder gleich aufwändig: Sie erhalten eine Priorisierung und eine Aufwandsschätzung, wodurch sie entweder so schnell wie möglich umgesetzt oder erst einmal weiter nach hinten geschoben werden. Diese Aufgabe erledigt das Entwicklerteam zusammen mit dem sogenannten Product Owner, dem Ansprechpartner aller Stakeholder des Projekts: Während dieser typischerweise die Priorität der Anforderungen basierend auf Faktoren wie dem Geschäftswert abwägt, bewerten die Entwickler den Umsetzungsaufwand.

  • Backlogs erzeugen Transparenz über erfasste Features, Epics, Use Cases, Use Case Slices und User Stories.
  • Backlogs strukturieren die Entwicklung von Applikationen, Produkten und Systemen sowohl inhaltlich als auch zeitlich.
  • Backlogs erfordern eine regelmäßige, eindeutige Priorisierung und sorgen in der Folge für eine hohe Akzeptanz der Stakeholder.
  • Backlogs sind ein sehr gutes Arbeitsmittel für die beteiligten Rollen und Mitarbeiter.
  • Backlogs sind stets aktuell und zeigen, woran gerade gearbeitet wird.

Haben wir Ihr Interesse geweckt? Wünschen Sie sich mehr Informationen über dieses oder ein anderes Thema?