Wer sollte die Aufgaben in Scrum definieren, zuweisen, implementieren und befolgen?

10

Rollen in Scrum sind Product Owner, Scrum Master und Scrum Team. Eine User Story sollte auch in kleinere Teile zerlegt werden, die als Aufgaben bezeichnet werden. Eine Aufgabe scheint vier Phasen zu haben, nämlich Definition, Zuweisung, Implementierung und Folgen.

Wer sollte was in Scrum über Aufgaben tun? Liegt es in der Verantwortung des Scrum Masters, die verbleibenden Stunden einer Aufgabe zu aktualisieren, oder liegt es in der Verantwortung des Entwicklers (Scrum-Teams)? Sollten sich Entwickler Aufgaben zuweisen oder liegt es in der Verantwortung des Scrum Masters, der vom Product Owner begleitet wird?

— Saeed Neamati
quelle

12

Agile folgt mehreren Prinzipien. Eine davon ist: Menschen stärken. Aus diesem Grund sollten Aufgaben vom Team definiert und Aufgaben von Teammitgliedern ausgewählt werden. Aufgaben sollten nicht dem Teammitglied zugewiesen werden. Das Team sollte sich selbst organisieren und aus diesem Grund sollte die Verteilung der harten / einfachen / interessanten / langweiligen Aufgaben gleichmäßig sein.

Der Scrum Master sollte sicherstellen, dass das Team den Scrum-Prinzipien folgt. Er ist kein Projektmanager.

Dies ist Theorie und funktioniert für reife Teams. Für Scrum-Anfänger kann es manchmal schwierig sein, aber Sie sollten zumindest darauf bestehen, dass die Teammitglieder die Aufgabe selbst auswählen, anstatt sie zuzuweisen.

Aktualisieren Sie die verbleibenden Stunden einer Aufgabe

Meiner Meinung nach ist es Verschwendung, Aufgaben zu schätzen und die verbleibende Zeit aufrechtzuerhalten. Sie haben sich für eine Reihe von User Stories engagiert, sodass es keine Rolle spielt, wie lange jede Aufgabe dauern wird. Das einzig Wichtige ist, ob die User Story abgeschlossen ist oder nicht.

— Ladislav Mrnka
quelle

3

Ich bin nicht der Meinung, dass das Schätzen von Aufgaben und das Aufrechterhalten der verbleibenden Zeit eine Verschwendung ist. Ich fand, dass die "verbleibende Zeit" das beste Frühwarnzeichen ist, das man bekommen kann, wenn Dinge unerwartet beginnen. Es muss nicht sehr genau sein, aber der Scrum-Master muss wissen, ob sich eine Schätzung A) nicht ändert oder B) erhöht. Dies kann häufig vorkommen, wenn ein verstecktes Hindernis (auch für den Entwickler) vorliegt. In einem neuen Scrum-Team hilft dies auch bei der Transparenz und verhindert, dass das "Ich habe x gestern gemacht, ich werde heute mehr x machen" aufsteht.

— Brook

@Brook: Das ist der Grund, warum Scrum das Burndown-Diagramm verwendet. Wenn Sie ein Burndown-Diagramm verwenden, um abgeschlossene User Stories (mit einer durch Story Points definierten Komplexität) anzuzeigen, erhalten Sie dennoch ein solches Feedback. Nach meiner Erfahrung ist das Feedback sogar noch besser, da Sie nicht (Beispiel) mit 10 Stunden nicht abgeschlossener Arbeit enden, was bedeutet, dass 10 User Stories mit jeweils 1 Stunde fehlen.

— Ladislav Mrnka

Wenn ich könnte, würde ich diese Antwort +10 geben. Genau richtig.

— Wolfgangsz

@Ladislav Mrnka: Sie werden ähnliche Daten aus dem Abbrennen erhalten, aber wenn die Arbeit noch übrig ist, erhalten Sie feinere Details und können Sie früher warnen. Es ist ein strittiger Punkt, wenn alle Ihre Aufgaben <Tag dauern, aber gelegentlich, wenn eine Aufgabe> 1 Tag dauert, kann die verbleibende Arbeit einen schnellen Hinweis darauf geben, ob Sie sich Sorgen machen müssen oder nicht. Normalerweise bitte ich die Leute nicht, sich Gedanken darüber zu machen, was auch immer ihr Bauchgefühl ist, es ist also nicht so umständlich, eine Metrik hinzuzufügen.

— Brook

Früher? Sprint sollte "kurz" sein - wie früh sollten Sie gewarnt werden? Ich habe eine sehr einfache Regel verwendet. Wenn wir nicht mindestens 1/3 der User Stories (Story Points) in der Hälfte des Sprints erstellt haben, können wir höchstwahrscheinlich nicht alles liefern, was wir begangen haben. Es hat ganz gut funktioniert und wir mussten nichts abschätzen. Bei Sprints, die 2 oder 3 Wochen dauern, brauchen Sie nicht viel mehr.

— Ladislav Mrnka

6

Sollten sich Entwickler Aufgaben zuweisen oder liegt es in der Verantwortung des Scrum Masters, der vom Product Owner begleitet wird?

An Orten, an denen ich gearbeitet habe, die Scrum gefolgt sind, haben wir beides getan, obwohl Entwickler im Idealfall ihre eigenen Aufgaben auswählen sollten. Letztendlich spielt es keine Rolle, solange alle Aufgaben erledigt sind.

Jeder Ansatz hat Vor- und Nachteile.

Lassen Sie das Team ihre eigenen auswählen:

Profis - das Team fühlt sich der Aufgabe verpflichtet, wählt diejenigen aus, bei denen es gute Arbeit leisten kann. Eigenverantwortung ist ein wichtiger Aspekt der Entwicklung, den viele Menschen übersehen.
Nachteile - Einige Aufgaben bleiben bis zum Ende, wenn sie zuerst besser erledigt werden.

Aufgaben zugewiesen bekommen:

Profis - alle Aufgaben werden gleichermaßen berücksichtigt und keine werden möglicherweise ausgelassen.
Nachteile - Die Teammitglieder fühlen sich nicht unbedingt der Aufgabe verpflichtet.

Im wirklichen Leben müssen Sie einen pragmatischen Ansatz verfolgen. Es wird Zeiten geben, in denen Aufgaben zugewiesen werden müssen, aber diese sollten nur wenige sein.

— ChrisF
quelle

+1 - für jemanden, der das letzte Wort hat. Jemand muss verantwortlich sein.

— JeffO

2

Ich schätze, dass ein gewisser Pragmatismus eine nützliche Sache ist, aber das Zuweisen von Aufgaben an Entwickler ist definitiv NICHT die Scrum-Methode, um Dinge zu tun.

— Wolfgangsz

@ChrisF: Können Sie klarstellen, wo in Scrum steht, dass ScrumMaster über die Berechtigung verfügt und dass andere den Entwicklern Aufgaben zuweisen dürfen?

— Martin Wickman

@ Martin - nein ich kann nicht. Hauptsächlich, weil es eine Weile her ist, seit ich mit Scrum gearbeitet habe. Der Pragmatiker in mir sagt jedoch, dass irgendwann jemand eine Entscheidung treffen muss.

— ChrisF

Ein bisschen spät im Spiel, aber meine 2 ¢ - Ich denke, wenn einige Aufgaben bis zum Ende verbleiben, wenn sie zuerst hätten erledigt werden sollen, bedeutet dies, dass Ihr Scrum Master (und Product Owner) diese Aufgaben nicht genug betont.

— Wayne Werner

2

In unserem Scrum-Prozess machen wir Folgendes:

Die Aufgaben werden von der Gruppe der Entwickler definiert, die höchstwahrscheinlich die User Story implementieren werden.

Mindestens zwei Entwickler sind für die Implementierung einer User Story verantwortlich, daher werden sie automatisch den Aufgaben zugewiesen (wenn sie parallel arbeiten können, übernehmen sie eine Aufgabe, die für sie aufgrund ihres Wissens und ihres persönlichen Geschmacks am besten geeignet ist. Andernfalls werden sie Programm koppeln).

— Benni
quelle

2

Wer aktualisiert die verbleibenden Stunden einer Aufgabe?

Nur die Entwickler können wissen, wie viel Arbeit noch übrig ist, und stellen die Informationen bereit. Es ist nicht wichtig, wer genau die Stunden aktualisiert.

Sollten sich Entwickler Aufgaben zuweisen?

Ja. Das Auswählen von Aufgaben für sich selbst ist leistungsstark, da Sie sich stark dafür einsetzen , diese Aufgaben auf eine Weise zu erledigen , die nicht möglich wäre, wenn jemand anderes sie Ihnen zuweisen würde.

— Martin Wickman
quelle

2

Scrum Guide

Alles, was mit Aufgaben zu tun hat, liegt in der Verantwortung des Teams in Scrum. Das Team wird in der zweiten Hälfte des Sprint-Planungsmeetings in der Regel eine Zerlegung der Geschichten in Aufgaben erstellen. Während des Sprints können jedoch jederzeit neue Aufgaben eingeführt oder Aufgaben entfernt werden, sobald neue Informationen bekannt werden. Meiner Meinung nach ist diese tägliche Rückkopplungsschleife ein wichtiger Bestandteil von Scrum.

Der ScrumMaster ist nicht der Teamleiter oder sein Manager. Die Rolle des ScrumMaster besteht darin, den Scrum-Prozess zu vereinfachen und Hindernisse zu beseitigen. Der ScrumMaster weist Entwicklern keine Aufgaben zu. Der Product Owner weist Entwicklern keine Aufgaben zu. Das Team liefert dem Produktbesitzer (und dem Kunden) durch die Implementierung der User Stories einen Mehrwert.

Das Team ist für alle Schätzungen verantwortlich. Es besitzt also die Schätzungen für die Aufgaben (und Geschichten) an der Tafel.

— Guy Sirton
quelle