Wir sind ein Beratungsunternehmen, das Projekte für eine Reihe unserer Kunden durchführt. Für einige Kunden gibt es einen Product Owner, der die Benutzergeschichte und die Akzeptanzkriterien schreibt (ich verstehe, dass Akzeptanzkriterien nicht obligatorisch sind, aber wir raten ihnen im Allgemeinen, da wir mit einer Vielzahl von Ressourcen in einem verteilten Setup arbeiten und daher detaillierte Akzeptanzkriterien haben ist immer hilfreich).
Es wird allgemein von allen akzeptiert, dass Akzeptanzkriterien verfügbar sein sollten, bevor die Entwicklung der Arbeit beginnt. Die Frage ist, wer die Akzeptanzkriterien schreiben sollte.
Ich bin der Meinung, dass der Product Owner die User Story schreibt, in der die Funktionsanfrage beschrieben wird, und die Akzeptanzkriterien eine Zusammenarbeit zwischen dem Entwicklungsteam (Entwickler oder Tester) und dem Product Owner sein und nicht unbedingt vollständig an den Product Owner übergeben werden sollten.
Es wäre also etwas in dieser Richtung.
User Story Als Contact-Center-Agent möchte ich grundlegende Informationen über den Kunden erfassen, wenn er anruft
Die Akzeptanzkriterien sollten sein
1. Datenerfassung
2. Validierung
Die Akzeptanzkriterien können vom Product Owner geschrieben werden, aber sie können auch vom Entwickler / Tester geschrieben werden, solange sie vom Product Owner abgezeichnet werden.
Ein Kollege erwähnte, dass das Problem, den Entwickler/Tester zu bitten, die Akzeptanzkriterien zu schreiben, darin besteht, dass es zusätzliche Arbeit ist. Sie erwähnten auch, dass es keinen Prozess gibt, um zu erfassen, dass der Product Owner die Akzeptanzkriterien unterschrieben hat, sodass sie sich möglicherweise umdrehen und sagen könnten, dass dies nicht das ist, was wir gefragt haben. (Der zweite Teil der Bedenken bezieht sich wahrscheinlich nicht auf Agilität, sondern bezieht sich eher darauf, wenn wir als Beratungsunternehmen arbeiten).
Also, wer sollte die Akzeptanzkriterien schreiben – liegt es in der vollständigen Verantwortung des Product Owners oder in der Verantwortung des Teams?
Zunächst sei gesagt, dass es hierzu keine festen Regeln gibt. Allerdings arbeiten die erfolgreichsten Teams, die ich sehe, so, wie Sie es beschreiben. Insbesondere erstellt die PO ein Backlog-Element mit anfänglichen Akzeptanzkriterien und zeigt es dem Team in der Backlog-Verfeinerung, und bei Bedarf erstellen sie gemeinsam weitere.
Und während das Backlog-Item „bereit“ sein sollte, bevor die Entwicklung beginnt, ist es nicht ungewöhnlich, dass der Akt der Entwicklung und des Testens neue Fragen aufdeckt, die den Input des PO erfordern, und die Antworten darauf können zu aktualisierten Akzeptanzkriterien führen.
Der Scrum Guide ist in diesem Punkt ziemlich klar:
„Der Product Owner kann die oben genannten Arbeiten durchführen oder das Entwicklungsteam damit beauftragen. Der Product Owner bleibt jedoch verantwortlich.“
Ihr Kollege hat darauf hingewiesen, dass die Schaffung von Akzeptanzkriterien Arbeit ist, und das ist es auch. Die Herausforderung besteht darin, dass Scrum Entwicklung als Teamleistung betrachtet, bei der jeder in alle Arten von Arbeit involviert ist. Das Verständnis für das Richtige zum Bauen ist genauso wichtig wie der Akt des Bauens, und die Einbeziehung der Entwicklung in diese Aktivität trägt dazu bei, dieses Verständnis aufzubauen.
Die andere Sache, die Ihr Kollege erwähnte, betraf den Prozess. Für die meisten Teams bedeutet die Tatsache, dass diese in einer Backlog-Verfeinerung mit Teammitgliedern und PO geschrieben werden, dass Sie praktisch sicher sein können, dass der PO davon Kenntnis hat und abgesegnet ist. Wenn Sie jedoch in Ihrem Fall etwas Konkreteres benötigen, ermöglichen die meisten Online-Prozessmanagement-Tools modifizierte Workflows. Ich weiß zum Beispiel, dass es möglich ist, benutzerdefinierte Flows in Jira zu erstellen, die einen PO auffordern, auf eine Schaltfläche zu klicken, um die Änderung in der User Story-Beschreibung abzumelden, die aktualisiert wurde. Ich gehe davon aus, dass viele andere Tools diesen Prozess auch für Sie übernehmen können. Es mag für Sie ein faires geschäftliches Anliegen sein, aber es sollte nicht schwer sein, es zu überwinden.
Bei den Akzeptanzkriterien geht es um die Benutzerfreundlichkeit. Wenn eine Funktion die Akzeptanzkriterien erfüllt, kann sie mit Sicherheit verwendet werden. Die Akzeptanzkriterien sind so klar wie schwarz/weiß.
Sehen Sie sich bitte dieses Video an: https://www.scrum.org/resources/definition-done-vs-acceptance-criteria
Jetzt kann jeder eine User Story schreiben und sie in das Product Backlog einfügen. Jede User Story muss verfeinert werden, bevor sie während der Sprintplanung in das Sprint Backlog aufgenommen werden kann.
Das bedeutet, dass jede von jemandem geschriebene User Story während des Product Backlog Refining-Meetings vom Entwicklungsteam und dem Product Owner besprochen wird. Sowohl das Entwicklungsteam als auch der Product Owner schreiben die Akzeptanzkriterien.
In der Praxis enthält die User Story bereits die Akzeptanzkriterien, wenn sie in das Sprint Planning Meeting eintritt oder die Akzeptanzkriterien, die sie während des Sprint Plannings durch das Entwicklungsteam und den Product Owner definiert.
Ein Kollege erwähnte, dass das Problem, den Entwickler/Tester zu bitten, die Akzeptanzkriterien zu schreiben, darin besteht, dass es zusätzliche Arbeit ist.
Diese Arbeit wird entweder während der Product Backlog Refinement oder der Sprint Planung durchgeführt.
Sie erwähnten auch, dass es keinen Prozess gibt, um zu erfassen, dass der Product Owner die Akzeptanzkriterien unterschrieben hat, sodass sie sich möglicherweise umdrehen und sagen könnten, dass dies nicht das ist, was wir gefragt haben.
Wenn es vom Product Owner vorgeschlagen wird, vom Entwicklungsteam in das Sprint Backlog aufgenommen zu werden, dann wissen wir, dass der Product Owner die Akzeptanzkriterien der User Story gelesen und ihnen zugestimmt hat.
Natürlich können sich die Akzeptanzkriterien während des Sprints weiterentwickeln. Alle Änderungen sollten spontan vom Entwicklungsteam und dem Product Owner besprochen werden.
Es bleibt keine Zeit, auf das nächste Product Backlog Refinement zu warten. Die User Story wurde bereits für diesen Sprint ausgewählt, daher muss die Diskussion so schnell wie möglich stattfinden.
Deshalb sollte der Product Owner dem Entwicklungsteam immer zur Verfügung stehen. Und deshalb gibt es bei Scrum/Agile kein „Abmelden“. Weil jede Funktion Änderungen erfahren kann, wenn das Entwicklungsteam tatsächlich mit der Implementierung beginnt.
Der Product Owner sollte dies so schnell wie möglich anerkennen und auf der Grundlage der neuen Informationen klarstellen, was es bedeutet, dass „das Feature verwendbar ist“.
Zum Beispiel:
Bei einer User Story geht es darum, etwas auf der Benutzeroberfläche sichtbar zu machen.
In der Praxis dauert die Benutzeranmeldung dadurch aufgrund einer großen, langsamen Anfrage an das Backend 5 Sekunden länger. Die User Story könnte also so geliefert werden, wie sie ist, aber ist sie brauchbar?
Ist es akzeptabel, dass die Benutzeranmeldung 5 Sekunden dauert? Dies ist eine Frage für den Product Owner.
Was ist die Alternative? Das Entwicklungsteam behauptet, dass es die Backend-Anfrage optimieren muss und möchte die Komplexität von 2SP auf 3SP erhöhen. Im Gegenzug bedeutet dies, dass eine weitere User Story möglicherweise nicht geliefert wird.
Was soll getan werden? Wahlmöglichkeiten für den Product Owner: 1. Liefern Sie die User Story wie ursprünglich beschrieben und akzeptieren Sie die zusätzliche Anmeldezeit von 5 Sekunden. 2. Aktualisieren Sie die User Story auf 3SP und optimieren Sie die Backend-Anfrage, indem Sie dieser User Story im Wesentlichen eine höhere Priorität einräumen als einer anderen (die in diesem Sprint möglicherweise nicht „fertig“ ist). 3. Stellen Sie zuerst andere User Stories bereit, beginnen Sie dann mit der Arbeit an dieser, aktualisieren Sie sie auf 3SP und liefern Sie sie möglicherweise in diesem Sprint nicht.
Der Product Owner muss die neuen Informationen ("5 Sekunden Benutzer-Login-Verzögerung") berücksichtigen und sofort entscheiden, was zu tun ist.