Backlog-Verfeinerung – automatisiert

Backlog-Verfeinerung

Bei der Backlog-Verfeinerung handelt es sich um die Aktivität, bei der Arbeitselemente für die Arbeit Ihres Softwareteams vorbereitet werden. Ihr Rückstand an User Stories, Entwickleraufgaben und epischen Ideen ist der Warteschlange potenzieller Arbeitselemente an denen in den kommenden Wochen gearbeitet werden soll (Sprints). Um einen stetigen Arbeitsfluss für das Team aufrechtzuerhalten, sollte eine Liste verfeinerter Backlog-Elemente bereitstehen, damit das Team jederzeit mit der Arbeit beginnen kann. Es dürfte etwas mehr sein bereit und priorisiert als das Team für die kommenden Sprints benötigt.

Was bedeutet Backlog-Verfeinerung?

Backlog-Verfeinerung (auch Backlog-Grooming genannt) bedeutet, an der Gültigkeit und den Details der Anforderungen/Ideen/Aufgaben zu arbeiten, damit die Schlüsselfragen richtig beantwortet werden, sodass der Entwickler/Tester gleich beim ersten Mal das Richtige tut. User Stories sollten verfeinert und fertig sein, bevor mit der Codierungs- und Testarbeit begonnen wird.

Um Ihre Backlog-Meetings zu verkürzen, möchten Sie, dass Ihr Input so hochwertig wie möglich ist. Das bedeutet, dass Sie Ihren Business-Analysten oder Product Owner bitten, die User Stories vor dem Meeting so weit wie möglich zu verfeinern. Eine automatisierte Analyse kann dabei wirklich hilfreich sein, da sie Ihnen dabei hilft, Ihre Geschichten vor dem Verfeinerungstreffen in einen guten Zustand zu bringen.

Was bedeutet eigentlich „bereit“?

Bereit, oder Definition von bereitbedeutet, dass VOR der Codierung ausreichende Überprüfungen, Fragen, Umformulierungen, Überprüfungen und Analysen durchgeführt wurden, sodass die Codierungsarbeit gleich beim ersten Mal richtig durchgeführt werden kann. Dies bedeutet, dass die Ziele des Benutzers vollständig verstanden, klar, im Idealfall messbar und sicherlich eindeutig sind, bevor eine Codezeile geschrieben wird. (Nb-Prototyping ist oft ein nützliches Mittel zur Überprüfung von Anforderungen, aber Prototyping ist nicht unbedingt gleichbedeutend mit Codierung.)

Eine verfeinerte User Story sollte sein:

Vereinfacht

Ihre User Stories sollten kurze, prägnante funktionale Aussagen sein, die die Funktionsschritte einer vollständigen Benutzeranforderung vollständig beschreiben. So dass sich das System vor und nach Durchführung der Schritte in einem stabilen Zustand befindet.

Geklärt

Ihre User Stories sollten klar, prägnant und eindeutig sein. Ideal ist es, wenn mehrere Mitglieder ihre Interpretation jeder User Story beschreiben. Jede Interpretation ist gleich. Mit der englischen Sprache ist das schwierig, manchmal sogar dann, wenn alle Beteiligten während des Gesprächs, in dem die User Story beschrieben wurde, anwesend waren. Das Ziel besteht darin, eine konsistente Interpretation durch alle Teammitglieder zu erreichen, d. h. A Gemeinsames Verständnis.

Benutzerorientiert

Wir sehen, dass viele User Stories mit „als Entwickler…“ beginnen. Dies beschreibt nicht die Anforderung aus der Perspektive des Benutzers, sondern ist eine Aufgabe.  Bevor Sie Entwickleraufgaben erstellen, müssen Sie zunächst eine User Story erstellen, die beschreibt, was der Benutzer erreichen muss und warum. Dann und nur dann können Sie dies bei Bedarf in Entwickleraufgaben aufteilen.

Konsistenz geprüft

Es ist wichtig, dass Sie in Ihren User Stories für jede Benutzerpersönlichkeit einheitliche Begriffe verwenden. Es ist außerdem wichtig, dass Sie für jeden Objekttyp identische Wörter verwenden. Dieses Problem tritt sehr häufig auf, wenn zwei oder mehr Personen die User Stories verfassen, kann aber auch auftreten, wenn nur eine Person die Arbeit erledigt. Die inkonsistente Verwendung von Objektnamen oder Benutzerpersönlichkeiten führt zu inkonsistenten Interpretationen und Fehlern.

Vollständigkeit geprüft

Ist Ihre User Story vollständig und beschreibt sie alle Funktionen, die zur Bereitstellung des Benutzererlebnisses oder der erforderlichen Funktionalität erforderlich sind? Haben Sie tatsächliche Funktionalität in Ihren Akzeptanzkriterien „vergraben“ (dies ist ein sehr häufiger Fehler)?

Wenn Sie Daten innerhalb eines Systems verwalten, ist es üblich, eine CRUD-Analyse durchzuführen und eine CRUD-Matrix zu erstellen. Dadurch können Sie sicherstellen, dass alle Daten von mindestens einem Prozess erstellt, gelesen, aktualisiert und gelöscht werden. Die CRUD-Analyse ist ein effizientes und effektives Mittel, um sicherzustellen, dass Ihre User Stories in sich konkurrenzfähig sind. Letztendlich müssen alle Daten vollständig von einem System verwaltet werden. Durch die frühzeitige Durchführung einer CRUD-Analyse erhalten Sie eine bessere Einschätzung des letztendlichen Umfangs Ihres Projekts.

Größe

Es ist wichtig, jede User Story, jedes Epic oder jede Aufgabe in Ihrem Backlog zu dimensionieren. Warum? Damit Sie die Arbeit planen und priorisieren können. Obwohl viele Teams die Idee von T-Shirt-Größen oder Story Points verwenden, sind diese von begrenztem Nutzen, da sie inkonsistent sind und keine absolute Bedeutung haben. Wir empfehlen:

• Aufgaben werden in Personalstunden oder Personaltagen bemessen.
• BenutzergeschichtenInsbesondere funktionale User Stories werden in COSMIC Function Points (CFPs) dimensioniert.
• Epen kann normalerweise in CFPs geschätzt werden.

Nb. CFPs für ein Team lassen sich normalerweise leicht in geschätzte Stunden umwandeln. Weitere Informationen zu COSMIC Function Points.

Priorisiert

Backlog-Elemente sollten priorisiert werden. Die Priorität (und die Reihenfolge der Elemente mit ähnlicher Priorität) sollte unter Berücksichtigung mindestens der folgenden Überlegungen bestimmt werden:

• Wert der Funktionalität für das Unternehmen, einschließlich wahrscheinlicher Nutzung
• Größe (bestimmt den wahrscheinlichen Aufwand zur Bereitstellung).
• Auswirkungen auf das Geschäft, wenn dies hinausgezögert wird. Kosten der Verzögerung.
• Technische Beziehung dieser Funktionalität zu anderen, also technische Abhängigkeiten
• Risiko von Unbekannten, die zu erheblichen Änderungen bei anderen durchgeführten Arbeiten führen könnten.

Eine gängige Technik, um einige dieser Überlegungen einem numerischen Wert zuzuordnen, heißt Weighted Shortest Job First (WSJF).

Colin Hammond, 2022

Automatisierte Backlog-Verfeinerung

In anderen Artikeln zu diesem Thema wird die Aufteilung von Geschichten und die Ausarbeitung von Geschichten erörtert. Wir halten diese Begriffe für etwas vage. Wir sind konkreter geworden, weil es wichtig ist, so zu sein. Ein falsches Wort in einer Anforderung kann zu einer Fehlinterpretation und möglicherweise stundenlanger Verschwendung führen, wenn der Code neu geschrieben werden muss.

Weiterführende Literatur von externen Seiten

Es fiel mir schwer, viele Artikel zu finden, die ich nachdrücklich befürworten kann. Ich empfehle dieses Buch Softwareanforderungen von Karl Wiegers und Joy Beatty

Digitaler Artikel zur Backlog-Verfeinerung