Nehmen wir an, das Entwicklungsteam plant den nächsten Sprint. Was bedeutet es technisch gesehen, dass eine User Story zum Sprint Backlog hinzugefügt wird? Ist es einem Entwickler oder dem gesamten Team zugewiesen? (Wenn es dem gesamten Entwicklungsteam zugewiesen ist, wie machen wir das dann in Jira?)
Wenn das Team einen Sprint plant, zieht es Product Backlog Items oder User Stories von der Spitze des Backlogs in seinen Sprint. Die Stories, die sie für diesen Sprint ausgewählt haben, bilden nun das „ Sprint Backlog “.
Nun, was die Zuordnung dieser Geschichten betrifft... es kommt darauf an .
Im Rahmen der Planung können Entwickler auch entscheiden, wer was macht. Jake könnte sich selbst Story 1 zuweisen, Jane könnte sich Story 2 zuweisen und so weiter. Das ist ein visueller Indikator dafür, wer welche Arbeit macht, aber es ist nicht wirklich obligatorisch. Alle Geschichten gehören dem Team, unabhängig von der Person, die daran arbeitet .
Ich habe zum Beispiel in einem Team gearbeitet, in dem wir die Geschichten nicht zugewiesen haben. Fast alle von uns waren Full-Stack-Entwickler, also nahmen wir einfach Geschichten und arbeiteten daran, sobald wir verfügbar wurden. Wir wussten, wer woran arbeitete, weil wir uns im selben Büro befanden, wir kommunizierten, wenn wir neue Sachen zur Arbeit nahmen, und wir synchronisierten und planten unsere Arbeit im Laufe des Tages. Geschichten wurden also von TODO nach IN PROGRESS verschoben, ohne jemandem zugeordnet zu werden. Jira hat damit kein Problem. Die Story wird in Jira einfach als UNASSIGNED angezeigt.
Es kommt also darauf an, was du machen willst. Wenn Sie die Informationen nützlich finden, können Sie eine Story zuweisen. Wenn nicht, weiß das Team immer noch, wie es sich organisieren und die Arbeit erledigen kann.
Der Scrum Guide vom November 2020 sagt:
Das Sprint-Backlog besteht aus dem Sprint-Ziel (warum), den für den Sprint ausgewählten Product-Backlog-Elementen (was) sowie einem umsetzbaren Plan für die Lieferung des Inkrements (wie).
In dieser Definition ist die Arbeitseinheit nicht definiert. Das heißt, das Product Backlog Item ist möglicherweise nicht die Arbeitseinheit, die von einem oder mehreren Mitgliedern des Entwicklungsteams erledigt wird.
Meiner Erfahrung nach machen die meisten Teams eines von zwei Dingen. Ein gängiger Ansatz besteht darin, die Product Backlog Items einem oder mehreren Mitgliedern des Entwicklungsteams zuzuweisen. Wie diese Arbeit verteilt wird, entscheidet das Team selbst, aber ein selbstorganisierendes Team zeichnet sich häufig durch Selbstaufgabe und Pull-Ansatz aus. Ein anderer Ansatz besteht darin, dass ein Team die Product Backlog Items in Teilaufgaben zerlegt und diese Teilaufgaben den Mitgliedern des Entwicklungsteams zuweist. Auch hier deuten Selbstaufgabe und Zugarbeit auf ein selbstorganisiertes Team hin.
Die genaue „Aufgabe“ hängt von den Praktiken des Teams und dem Tooling ab. Bei Praktiken wie Pair Programming und Mob Programming arbeiten zwei oder mehr Personen an einer einzelnen Arbeitseinheit, sodass es keinen einzelnen Beauftragten gibt. Aber auch in diesen Fällen kann sich ein Team dafür entscheiden, dass eine einzelne Person das „Eigentum“ der Arbeit erhält, und sie würde als Bevollmächtigter identifiziert werden. Die Werkzeuge sind ebenfalls von Bedeutung, da Werkzeuge möglicherweise Beschränkungen unterliegen, wer als Bevollmächtigter zugelassen ist. Beispielsweise lässt Jira nur eine Person im Beauftragtenfeld zu, sodass Teams dieses Feld leer lassen, Teamkonten erstellen oder benutzerdefinierte Felder als Problemumgehung verwenden können.
Insbesondere in Jira haben Sie mehrere Möglichkeiten:
Es ist Sache des Teams, das Sprint-Backlog basierend auf den vom Product Owner ausgewählten Backlog-Elementen zu erstellen. Einige Teams verwenden Sprint-Planung, um zumindest einige Elemente einzelnen Entwicklern zuzuweisen, andere Teams verwenden ein „Pull-System“, was bedeutet, dass Elemente nicht vorab zugewiesen werden und es an jedem Einzelnen liegt, Elemente aus dem Rückstand zu holen, wenn er die Kapazität hat dazu.
Wenn in Jira ein Problem von mehr als einer Person bearbeitet werden soll, ist es am einfachsten, wenn jeder Entwickler seine eigenen separaten Unteraufgaben erstellt, die ihm selbst zugewiesen werden.
Eine „Story“ entspricht nicht unbedingt 1:1 einer Entwicklungsaufgabe. Sie müssen anhand der Geschichte bestimmen , was getan werden muss und von wem, um sie abzuschließen.
Da Sie nach User Stories fragen, nicht nach Aufgaben: Eine User Story besteht in der Regel aus mehreren Aufgaben, die von verschiedenen Teammitgliedern, manchmal sogar unterschiedlichen Gewerken, angegangen werden können. Das bedeutet, dass Sie zwar Teammitglieder für jede der Aufgaben der Story zuweisen können (obwohl Sie das auch nicht tun müssen), die Story jedoch eher dem Team als Ganzes gehört .
Natürlich kann es Ausnahmen geben. Sie könnten zum Beispiel eine User Story haben, die komplett aus Aufgaben besteht, die nur von einem Spezialisten im Team gelöst werden können, also könnte es sinnvoll sein, die Story dieser Person zuzuweisen, um das sichtbar zu machen.
Wir haben das Eigentum an den Komponenten (es gibt jeweils einen Geschäftsleiter und einen Entwicklungsleiter).
Wir persönlich haben die Zuweisung des Tickets zum DEV-Lead nicht automatisiert, sondern die Zuweisung zum Business-Lead gemäß der Komponente automatisiert (erste im Ticket erwähnte Komponente – verantwortlicher Verantwortlicher – ist in den Projekteinstellungen in JIRA eingerichtet).
Sobald die Story für die Entwicklung bereit ist, weist der Business Lead/normale Analyst sie dem richtigen DEV-Lead zu (um die Code-Eigentümerschaft loszuwerden, gibt es eine Rotation der DEV-Leads, also beziehen wir uns auf eine bestimmte Tabelle zum Thema Confluence – es ist vom Projektleiter aktualisiert).
Es ist für uns relevanter, da der Geschäftsleiter immer die richtige Person kennt, da der Geschäftsleiter normalerweise mit dem DEV-Leiter der Komponente bei der LOE-Schätzung, Angeboten an den Kunden usw. zusammenarbeitet.
Scheint ein wenig Overhead zu sein, ist es aber nicht.
Wie Bogdan bereits erwähnte: „Das Team besitzt alle Geschichten“, und das Team sollte auch die Art und Weise besitzen, wie diese Geschichten fertig werden. Ich meine, die Vorabzuweisung an ein einzelnes Mitglied oder das Ziehen beim Sprintfortschritt sind beide in Ordnung.
Eine Praxis in meinem Team ist, dass wir immer einzelne Eigentümer auf Story-Ebene haben, selbst wenn mehrere Mitglieder beteiligt sind. Der Eigentümer ist (vor dem Team) dafür verantwortlich, alle Teilaufgaben und relevanten Mitglieder zu erleichtern, um die gesamte Geschichte zu erledigen.
Bogdan