Schätzt jemand Geschichten pro Disziplin in einer einzelnen Geschichte?

Idealerweise ist eine User Story eine vollständige Aussage über den Geschäftswert, und die Schätzung ist die Gesamtschätzung für alle Aufgaben und Tests , die erforderlich sind, um die User Story zu liefern.

Was Sie beschreiben, segelt in das Gebiet der Komponenten, indem Sie Benutzergeschichten schreiben, die ausschließlich einer Komponente gewidmet sind

• Als Front-End-Entwickler möchte ich einen Button erstellen, da der Back-End-Entwickler keine Schaltflächen usw. erstellt (1 Punkt)
• Ich bin ein Dienstentwickler und werde eine API erstellen, die ich über den Zaun werfe, damit das Frontend die Daten usw. anzeigt (8 Punkte).

Dies führt zu einer Abschottung von Rollen und Fähigkeiten, anstatt funktionsübergreifende User Stories zu erstellen.

Ideal wäre die Geschichte

• Als Kundendienstmitarbeiter möchte ich auf das letzte Datum zugreifen, an dem der Kunde das Unternehmen kontaktiert hat

^^ Diese Geschichte würde einen Teil der Entwicklung erfordern, einschließlich Überlegungen zur Back-End-, Front-End- und Lösungsarchitektur.

Die Schätzung sollte die Gesamtschätzung für alle Aufgaben/Unteraufgaben und erfolgreiche Tests sein. Dem Design sollten keine separaten Punkte zugewiesen werden, denn wenn die Geschichte nicht entworfen ist, kann sie die Definition von „Bereit“ nicht bestehen, um bearbeitet zu werden. Ein grundlegendes Design/Verständnis/Gliederung/Drahtmodell sollte bereit sein, damit die Entwickler Schätzungen abgeben können.

Ein gängiger Ansatz besteht darin, die Sprintplanung in zwei Teile aufzuteilen.

Im ersten Teil der Planung arbeitet das Team mit dem Product Owner zusammen, um dem Sprint Stories zuzuordnen. Sie schätzen als Team Story Points ein und stützen ihre Kapazität auf die Geschwindigkeit, die aus früheren Sprints berechnet wurde.

Im zweiten Teil der Planung unterteilt das Lieferteam jede Geschichte in Aufgaben, von denen einige disziplinspezifisch sein können. Das Team kann auch eine zeitbasierte Schätzung der Aufgaben vornehmen. Beachten Sie, dass diese Schätzungen nicht verwendet werden, um die Kapazität des Sprints zu ermitteln. Stattdessen werden sie verwendet, um hervorzuheben, ob eine bestimmte Disziplin überlastet ist. Einige Teams versuchen auch, die Größe der Aufgaben auf maximal 5 Stunden zu begrenzen. Größere Aufgaben werden heruntergebrochen.

Sobald der zweite Teil der Planung abgeschlossen ist, kann das Lieferteam den Product Owner bitten, eine Änderung der dem Sprint zugewiesenen Stories in Betracht zu ziehen, damit die Arbeit zwischen den Disziplinen gut ausbalanciert ist.

Es ist erwähnenswert, dass die erfolgreicheren Teams Teammitglieder mit sogenannten T-förmigen Profilen haben. Das heißt, sie sind in einer Disziplin sehr kompetent, aber auch bereit, in anderen Disziplinen zu arbeiten. Teams wie dieses sind viel besser in der Lage, mit den unvermeidlichen Unterschieden in der Arbeitsbelastung für die verschiedenen Disziplinen über Sprints hinweg umzugehen.

Das Agilste ist, wenn es für Sie funktioniert, tun Sie es einfach! Außerdem scheinen Sie nicht der einzige zu sein, denn mit den standardmäßigen agilen Projektmanagement-Tools von Taiga können Sie Story-Points pro Disziplin aufteilen. Sie haben standardmäßig vier Disziplinen: UX, Design, Front und Back.

Sie können es immer für ein paar Iterationen ausprobieren und sehen, ob es einen Mehrwert bringt. Wenn nicht, kehren Sie zu einer einzelnen Schätzung zurück.