User Story

Eine User Story ist eine kurze Beschreibung (Story) dessen, was ein Benutzer (User) will. User Stories werden bei der Entwicklung von Produkten oder Software innerhalb von Agile-Frameworks verwendet, zu denen auch Scrum gehört. Eine User Story besteht aus ein paar Sätzen, in denen beschrieben wird, was der Benutzer des Produkts machen will bzw. muss. Eine User Story ist im Regelfall wenig detailliert und sollte auf einen Klebezettel passen. Über die User Story beeinflusst der Benutzer die Entwicklung eines Systems oder Produkts und letztendlich auch dessen Funktionalität.

Woraus setzt sich eine User Story zusammen?

Eine User Story besteht aus drei Teilen:

  • Beschreibung in der Form: „Als [Rolle] möchte ich [Funktionalität], damit ich [Grund]“
  • Gespräch / Diskussion über die User Story, um die Einzelheiten zu besprechen. Die Einzelheiten werden festgelegt. Dies erfolgt beim Backlog Grooming oder während der Sprint Planning.
  • Testdetails, mit denen ermittelt wird, ob die User Story vollständig ist. Dies nennt man die Abnahmekriterien und die Definition of Done.

Alle Informationen zur Sprint Planning? Schauen Sie sich unser Animationsvideo an.

Über welche Eigenschaften verfügt eine gute User Story?

Eine User Story ist:

  • I – Independent: Sie beschreibt Funktionen, die unabhängig voneinander implementiert werden können.
  • N – Negotiable: Sie ist verhandelbar. Anders als bei herkömmlichen Projekten ist die User Story nicht vollständig vordefiniert. Somit erhält das Entwicklungsteam den Freiraum, eine User Story nach eigenem Ermessen möglichst optimal umzusetzen.
  • V – Valuable: Sie nützt mindestens einem Stakeholder.
  • E – Estimable: Sie kann dafür sorgen, dass das Team die Komplexität und die erforderlichen Kapazitäten bestimmt, um die User Story realisieren zu können.
  • S – Small: Die Umsetzung der User Story darf nicht mehr Zeit in Anspruch nehmen als ein Sprint. User Stories, die später verwirklicht werden, können länger dauern. Eine User Story, die zu umfangreich ist, um in einem Sprint realisiert zu werden, wird auch Epic genannt.
  • T – Testable: Die Stakeholder und der Product Owner kennen den Inhalt der User Story genau und wissen, welche Inhalte in Tests bewertet werden. Dies wird in den Abnahmekriterien und der Definition of Done formuliert.

Empfehl uns deinen Freunden
Email this to someone
email
Share on LinkedIn
Linkedin
Tweet about this on Twitter
Twitter
Share on Facebook
Facebook