Product Backlog Refinement (PBR) ist der kontinuierliche Prozess zur Verbesserung der Liste der zu erledigenden (Software-)Arbeiten. Das Züchterrecht ist der Grundstein für die Entscheidung, was in welcher Reihenfolge getan werden muss. In diesem Artikel beschreiben wir die Hauptaktivitäten der Produkt-Backlog-Verfeinerung und wie diese mit dem intelligenten Anforderungsanalysator von ScopeMaster® beschleunigt werden können.
Verfeinerung des Produkt-Backlogs
Die Verfeinerung des Produkt-Backlogs ist die regelmäßige Aktivität, die der Großteil oder das gesamte Team in einer Besprechung durchführt, mit dem Ziel, Aktivitäten für die bevorstehende(n) Iteration(en) vorzubereiten. Die wichtigsten Aktivitäten sind:
- Klärung von User Stories, damit das Team ein gemeinsames Verständnis davon hat.
- Geschichten spalten die zu groß sind, um in eine Iteration zu passen.
- Erstellen neuer User Stories und andere entsprechend neuem Wissen entfernen.
- Kostenvoranschlag zuweisens zu Geschichten
- Prioritäten zuweisen zu Geschichten
Die Verfeinerung des Produkt-Backlogs ist eine sehr zeitaufwändige und kostspielige Aktivität, die in der Regel 5–151 TP3T der gesamten Arbeitszeit der Teams in Anspruch nimmt. Dennoch ist es absolut notwendig, da es der entscheidende Schritt ist, um sicherzustellen, dass das Team an den richtigen Dingen arbeitet. Wenn hierfür nicht genügend Zeit und Mühe aufgewendet wird, verschwendet das Team Zeit mit den falschen Aktivitäten, was noch kostspieliger sein kann.
Schauen wir uns jede dieser PBR-Aktivitäten etwas genauer an und sehen, wie die Automatisierung helfen kann.
Was steht im Product Backlog?
Ein Produkt-Backlog enthält im Allgemeinen User Stories (die die Funktionalität beschreiben), Epics mit hoher Granularität und detailliertere User Stories. Das Produkt-Backlog sollte andere Aufgaben ausschließen, die möglicherweise beteiligt sind, aber nicht direkt Benutzerfunktionen bereitstellen.
Aktivitäten der Backlog-Verfeinerung:
1. Klärung von User Stories
Die englische Sprache ist immens flexibel. Wir haben viele alternative Wörter für dasselbe. Wir können die Wortreihenfolge ändern, um die Bedeutung zu ändern und die Art und Weise zu ändern, wie die Geschichte interpretiert wird. Die Variationen sind nahezu unbegrenzt, selbst eine User Story mit 12 Wörtern weist 87 Milliarden Permutationen der Wortreihenfolge auf. Bei jeder Variation wird die Interpretation des Lesers wahrscheinlich etwas anders ausfallen. Und selbst dann hängt die Interpretation einer User Story durch jeden Einzelnen von seinem eigenen Wortschatz und seinen eigenen Sprachkenntnissen ab. Es ist mehr als wahrscheinlich, dass zwei Personen, die eine User Story lesen, unterschiedliche Interpretationen haben.
Wenn die Mitglieder des Teams kein gemeinsames Verständnis eines Backlog-Elements haben, ist es wahrscheinlich, dass diejenigen, die anschließend daran arbeiten, Zeit damit verschwenden, das Falsche zu erstellen/zu testen. Ein einheitliches Verständnis des gesamten Teams ist daher unerlässlich, um unnötigen Aufwand zu minimieren.
Entsprechend scrum.org „Normalerweise durchläuft ein Product Backlog-Element drei Verfeinerungsbesprechungen, bevor es als bereit betrachtet wird.“ Um diese Diskussion fruchtbar zu machen, gilt: Je besser die Qualität der in das Meeting eingebrachten Geschichte ist, desto weniger Zeit wird verschwendet.
Die meisten Backlog-Elemente beschreiben die funktionale Absicht WHO Und Was der User Story. Hier kann ScopeMaster Unklarheiten in einem Bruchteil der Zeit vollständig beseitigen und langwierige Diskussionen überflüssig machen.
2. Storys so aufteilen, dass sie in einen Sprint passen
Agile User Stories sollten innerhalb einer einzigen Iteration oder eines Sprints (normalerweise zwei Wochen) abgeschlossen sein. Die Fertigstellung einer einzelnen Story sollte sich nicht über zwei Sprints erstrecken. Der Abschluss sollte auch alle Unit-Tests umfassen. Wenn eine Geschichte zu umfangreich ist, muss sie in mundgerechte Stücke aufgeteilt werden. Normalerweise kann ein Entwickler (einschließlich Unit-Tests) etwa 8 COSMIC Function Points (CFP) pro Sprint erstellen. Diese Schätzung der individuellen Produktivität variiert erheblich, aber wenn eine einzelne Story 8 CFP überschreitet, sollte sie entweder von mehr als einem Teammitglied geteilt und/oder in kleinere „Häppchen“ aufgeteilt werden, die jeweils innerhalb eines Sprints/einer Iteration abgeschlossen werden können.
Die Fähigkeit von ScopeMaster, die funktionale Größe zu erkennen, bietet eine sofortige Schätzung davon, ob eine Geschichte aufgeteilt werden muss.
3. Neue User Stories erstellen und andere entfernen
Softwareteams müssen sich an die sich ändernden Anforderungen des Unternehmens anpassen. Bei der Verfeinerung des Backlogs müssen einige Storys aufgeteilt, neue erstellt und andere entfernt werden. Dadurch wird sichergestellt, dass die geleistete Arbeit auf den derzeit bekannten Geschäftsbedarf ausgerichtet ist. Es ist in Ordnung, neue Geschichten zu erstellen, um den sich ändernden Anforderungen gerecht zu werden. Änderungen sollten jedoch so gering wie möglich gehalten werden, da übermäßige Änderungen das Team stören. Viele „Unbekannte“ sind tatsächlich „erkennbar“. Die Änderungen sollten auf die Dinge beschränkt werden, die zunächst nicht erkennbar waren. Wo immer möglich, ist es hilfreich, die Gesamtanforderungen so früh wie möglich zu antizipieren. Dies hilft, die Arbeit des Teams am effizientesten zu planen.
Die Fähigkeit von ScopeMaster, eine Reihe von User Stories auf fehlende und doppelte Funktionalität zu analysieren, ermöglicht es dem Team, viel früher ein besseres Verständnis des Gesamtumfangs zu erlangen.
4. Zuweisen von Schätzungen zu Storys
Das Schätzen von Storys ist möglicherweise einer der zeitaufwändigsten Aspekte bei der Verfeinerung des Produkt-Backlogs. Typischerweise handelt es sich dabei um das Spielen von „Story Poker“, bei dem die Teammitglieder den Aufwand erraten, der erforderlich ist, um die Geschichte in T-Shirt-Größen oder später in (beliebigen) Story Points zu vermitteln. Es ist nicht nur zeitaufwändig, sondern auch ermüdend, subjektiv, inkonsistent und für das Projektmanagement, insbesondere bei Großprojekten, von geringem Nutzen. Darüber hinaus werden Story-Point-Schätzungen in der Regel „ausgespielt“, um ein bestimmtes Ergebnis zu erzielen.
Die Fähigkeit von ScopeMaster, sofort schätzen Die funktionale Größe der User Stories (in COSMIC-Funktionspunkten) bedeutet, dass das Team nur sehr wenig Zeit in den Besprechungen aufwenden muss, um die Größe der Story zu besprechen. Die funktionale Größe der verfeinerten Geschichte ist ein konsistenter, standardisierter und unveränderlicher Wert. Dies gibt dem Team Zeit, die besten Möglichkeiten zu besprechen Wie um die Geschichte möglichst effizient zu vermitteln.
5. Den Geschichten Prioritäten zuweisen
Die Priorisierung von Storys ergibt sich daraus, wie wichtig sie für das Unternehmen sind, von welchen anderen Storys sie abhängen und wie viel Aufwand sie für die Bereitstellung aufwenden müssen. Wenn die anderen Backlog-Verfeinerungsaktivitäten bereits teilweise oder größtenteils automatisiert wurden, kann das Team mehr Zeit damit verbringen, dies in den Backlog-Verfeinerungsbesprechungen zu besprechen. Dadurch wird sichergestellt, dass das Team dies tut am wichtigsten Dinge in der richtigen Reihenfolge.
