Könnte der Product Owner ein Benutzer einer User Story in Scrum sein?

Der Product Owner wird nur dann in einer User Story genannt, wenn Sie ein Produkt entwickeln, das für Product Owner entwickelt wurde.

Ich muss einige Anforderungen schreiben, die sich direkt auf das Produkt beziehen, aber nicht genau auf jeden Benutzer, aber notwendig, um das Produkt zu erreichen.

Werden die Nutzer des Produkts in der Anforderung wirklich überhaupt keinen Wert sehen? Wenn das stimmt, warum verschwenden Sie Zeit damit?

Auch nicht-funktionale Anforderungen können im Sinne eines Benutzers geschrieben werden:

Als Benutzer des Produkts möchte ich, dass es auch unter hoher Last reaktionsfähig ist, damit ich eine gute Erfahrung mache

Als Benutzer des Produkts möchte ich sicher sein, dass ich im Falle eines Hardwareausfalls keine meiner Daten verliere, um sie nicht zeitaufwändig neu eingeben zu müssen

Als Marketingleiter möchte ich Statistiken über die Verwendung des Produkts sehen, damit ich schnell Entscheidungen über Marketingkampagnen treffen kann

Vermeiden Sie es, technische Aufgaben in User Stories zu integrieren. Zum Beispiel:

Als Product Owner möchte ich, dass eine Datenbank erstellt wird, damit wir das Produkt erstellen können

Packen Sie diese Anforderungen stattdessen als Teilaufgaben in eine echte Benutzeranforderung ein.

Zum Beispiel:

Als Benutzer möchte ich mich beim Produkt anmelden können, damit ich auf seine Funktionen zugreifen kann

Dies ist die erste Geschichte, die das Team macht, und um sie zu erreichen, haben sie möglicherweise Unteraufgaben, die Folgendes beinhalten: Erstellen eines Datenbankschemas, Erstellen einer Datenbank, Einrichten eines Datenbankservers, Einrichten eines Anwendungsservers, Erstellen eines Authentifizierungsframeworks usw.

Zwei Dinge fallen mir ein.

Erstens, wenn Sie die Notwendigkeit nicht zu einem vom System betroffenen Stakeholder zurückverfolgen können, ist es dann tatsächlich eine Anforderung? Unnötige Funktionen und Vergoldung sind Verschwendung im Lean-Sinne. Nur weil Sie es nicht zu einer bekannten Benutzerklasse zurückverfolgen können, heißt das nicht, dass es nicht gültig ist – es könnte schwierig sein, einige nicht funktionale Anforderungen, infrastrukturbezogene Aufgaben oder regulatorische/Compliance-Anforderungen im User Story-Format auszudrücken.

Zweitens, wenn es sich um eine gültige Anforderung an das System handelt, muss es als User Story ausgedrückt werden? Erwägen Sie für nicht-funktionale Anforderungen die Verwendung der Definition of Done, um festzustellen, wie das System nach der Implementierung einer Story sein sollte. Sicherheitsanforderungen, Leistungsanforderungen, Benutzerfreundlichkeitsanforderungen und andere können auf diese Weise am besten ausgedrückt werden. In anderen Fällen kann es einfach etwas sein, das getan werden muss, um andere Arbeiten zu ermöglichen – beschränken Sie sich nicht unnötigerweise auf das User Story-Format.

Ohne die spezifische Anforderung zu sehen, die Sie ausdrücken möchten (und vielleicht ein tieferes Verständnis des zu entwickelnden Systems), ist es leider nicht möglich zu sagen, in welche Kategorie Ihre Anforderung fällt – eine unnötige Anforderung oder eine, die einfach anders ausgedrückt werden sollte Weg.

Sicher, der Product Owner kann eine legitime Rolle in einer User Story spielen. Dasselbe gilt für einen Entwickler, einen Systemadministrator oder so weiter. Das Wichtigste ist, die Rolle zu identifizieren, die von dem durch das Ziel gelieferten Geschäftswert profitieren wird. Mit anderen Worten, verwenden Sie nicht einfach standardmäßig die Bestellung als Alternative zu „Benutzer“.

Manchmal ist es einfacher, eine Ebene höher zu gehen, um die passende Rolle zu finden. Vielleicht hast du ein Epos:

Als (Rolle) möchte ich, dass das Produkt archivierbar ist, damit (Geschäftswert).

Diese Geschichte könnte auf verschiedene Weise vervollständigt werden:

Als Systemadministrator möchte ich, dass das Produkt archivierbar ist, damit ich Backups erstellen und im Katastrophenfall wiederherstellen kann.

Als Vertragsbeauftragter möchte ich, dass das Produkt archivierbar ist, damit ich ein Archiv davon übergeben kann, um eine Vertragsleistung zu erfüllen.

Sobald Sie den geschäftlichen Wert der Erstellung des Archivs geklärt haben, sollte die Rolle klarer werden. Wenn das Gespräch mit dem PO schwierig ist, könnte ich versuchen: „Können Sie mir sagen, was Sie mit dem archivierten Produkt machen werden, sobald Sie es haben?“