Wie arbeiten Sie unbestimmbare Aufgaben in einem Scrum Sprint?

Question

Ich bin der Scrum Master für ein kleines Team von 4 Entwicklern. Das Projekt, an dem wir arbeiten, hat viele Aufgaben, die wir noch nie zuvor erledigt haben und die wir in einem Sprint-Planungsmeeting nicht leicht abschätzen können. Was ist der beste Weg für mich, um mit dieser Unsicherheit einen Sprint zu machen? Ich finde es sehr schwierig, einen Sprint mit einem potenziell freisetzbaren Produkt zu beenden. Es fällt mir auch schwer, Sprints zu planen, wenn es viele unbekannte Aufgaben gibt.

Answer 1

Ich bin nicht sicher, was der Begriff in Scrum ist, aber in der User Story-Terminologie würden Sie einen "Spike" machen, was im Grunde eine sehr kurze Zeit der Erforschung des Themas ist, so dass Ihr Team abschätzen kann die Aufgabe am Ende der Spitze.

Beispiel:

Story:

Analyst will in der Lage sein Finanzdaten in Kreisdiagramme zu überprüfen.

Ihr Team verwendet keine Diagrammwerkzeuge, Sie müssen also wissen, wie lange es dauern würde, um so etwas zu erstellen. Oder vielleicht könnten Sie stattdessen in Werkzeuge von Drittanbietern investieren und einen Werkzeugsatz in Ihre Anwendung integrieren.

Sie würden einen Spike machen, um diese Schauplätze zu recherchieren und mit Schätzungen zu kommentieren, und dann entscheiden, welche Route Sie nehmen sollen.

Answer 2

Wenn die Aufgaben unschätzbar scheinen, denke ich, der beste Ansatz wäre, diese Aufgaben in kleinere Aufgaben zu zerlegen, die Sie schätzen können. Es könnte mehrere Iterationen dauern, aber Sie werden wahrscheinlich mit einem Pseudo-Design kommen, wenn Sie gerade dabei sind. Joel erwähnt dies in einem seiner articles.

Answer 3

Teilen Sie die unschätzbare Aufgabe in eine Aufgabe, um die Unsicherheit zu beseitigen, und "den Rest". Entfernen Sie Unsicherheiten mit Proof-of-Concept-Tests oder Spike-Lösungen. Entweder plant die Spikes diesen Sprint und den Rest der Arbeit nächsten Sprint, Oder verzögern Sie den Beginn des Sprints für eine Woche von Spike.

Answer 4

Sind die "Aufgaben" Dinge, die jemand auf der Welt zuvor getan hat, oder sind sie nur neu in Ihrem Team. Ich nehme das später an. Wenn dies der Fall ist, was Sie finden, ist, dass Sie nicht die notwendige Erfahrung in Ihrem Team haben, um das Problem zu lösen. So wirst du diese Erfahrung entwickeln, während du gehst. All dies bedeutet, dass die Komplexität Ihrer Geschichten höher ist. In den ersten paar Sprints können Sie einige der Geschichten als 13 und dann später werden sie 8, weil Sie dann das Wissen haben, das Sie brauchen.

Sie müssen nicht wissen, wie man die Geschichten macht, um sie zu schätzen. Sie müssen nur weniger von ihnen aufgrund Ihrer Erfahrung Lücke nehmen.

Ich möchte "Spikes" reservieren (ja, das ist der Begriff in Scrum verwendet) für den Versuch, Business Domain Probleme zu lösen, die keine bekannte Lösung haben. Nicht für das Team, um zu trainieren.

Answer 5

Wir wissen oft nicht genug, um eine Geschichte in Aufgaben zu zerlegen. Wir haben eine Zeit der Entdeckung, bevor wir wissen, was die Aufgaben sein werden. "Spikes" scheinen schwierig zu sein. Zum einen können Sie den Entdeckungszeitraum möglicherweise nicht zeitgesteuert verarbeiten. Zweitens kann ich einen Sprint nicht effektiv planen, ohne zu wissen, wie lange eine Geschichte dauern wird.

Scheint wie eine andere Option ist, den Spike in Sprint 1 und die Aufgaben in Sprint 2 zu tun. Der Nachteil ist, dass es scheint, dass der Prozess einen unnatürlichen Zusammenbruch der Arbeit erzwingt. Warum diese Woche entdecken und dann eine Weile warten, bevor Sie mit der Arbeit beginnen.

Answer 6

Wenn Sie wirklich recherchieren müssen, um einen guten Kostenvoranschlag zu erhalten, können Sie die Recherche als eine Aufgabe an sich selbst durchführen oder sie vor der Sprintplanung beiseite legen und (von jemandem) erledigen lassen.

Im Allgemeinen denke ich, dass, wenn Sie keine gute Schätzung erhalten können, sollten Sie entweder mit einem schlechten Schätzwert gehen (dh eine wilde Schätzung) oder Sie sollten die Aufgabe zeit-box, so dass Sie eine feste Menge von Zeit dafür im Sprint. Danach haben Sie entweder eine fertige Lösung, oder Sie haben eine bessere Unterschätzung davon, so dass Sie es abschätzen oder in Teilaufgaben für den nächsten Sprint (oder einen späteren Sprint) zerlegen können.

Answer 7

Meinen Sie wirklich Aufgaben oder sprechen Sie über Product Backlog Items (PBIs)? Eigentlich fällt es mir schwer zu glauben, dass eine Aufgabe nicht schätzbar ist. Wenn sie es wirklich nicht sind, sind sie sehr wahrscheinlich zu groß (Aufgaben sollten nicht länger als 16h sein, was schon sehr groß ist).

Wenn Sie über PBIs sprechen, ist die Situation, die Sie beschreiben, ziemlich überraschend und sollte theoretisch nicht passieren. Geben Sie ihnen im schlimmsten Fall eine hohe Anzahl von Story-Punkten, das bedeutet genau, dass sie sehr unsicher sind. Da PBIs, die für einen Sprint bereit sind, die Hälfte Ihrer Geschwindigkeit nicht überschreiten sollten (oder Sie riskieren zu viel Sprint), ist der offensichtliche Weg, diese Situation zu lösen, die Aufteilung dieser Elemente in kleinere Teile Einbeziehung der Exploration. Aber der wichtige Teil ist, die Dinge Timeboxed, sogar (oder besonders) R & D. Denken Sie daran, dass mit Scrum alles Timeboxed ist.

Mit anderen Worten, um Ungewissheit zu reduzieren, brechen Sie Dinge in kleinere Dinge (seien es Gegenstände oder Aufgaben)!

Answer 8

Wir verwenden "Kontingente" oder einen spezifischen Rückstand für solche Aufgaben. Die Scrum Tool Agilo unterstützt diese Arbeitsweise und berechnet diese Probleme auch, z. im Burndown. Auf diese Weise erhalten Sie eine gute Kontrolle über die "nicht planbaren" Gegenstände.

Answer 9

Sie verwechseln Genauigkeit mit Genauigkeit?

Die Idee hinter Agile Schätzung ist es, mit einer Zahl zu kommen, die gut genug ist, nicht eine Zahl, die genau ist. Aus diesem Grund ist die Verwendung von Story-Points zur Schätzung von Backlog-Items eine bewährte Methode. es betont Anstrengung/Komplexität statt Dauer.

Sie müssen nicht wissen, wie lange jede Aufgabe benötigt wird, um ein Backlog-Element in einem Sprint zu implementieren. Was Sie wissen müssen, ist angesichts der Arbeit, die Sie in diesem Sprint zuvor begangen haben, können Sie sich auf dieses Rückstandsobjekt festlegen? Da wir wissen, dass wir nicht genau wissen können, wie viel Zeit jedes Backlog-Element benötigt, müssen wir eine fundierte Schätzung machen.

Wichtiger, was bedeutet es in Scrum zu scheitern? Wird nicht jedes Sprint-Backlog-Item fehlgeschlagen? Nein, wenn du vier von fünf Items hast und der fünfte meist erledigt ist, erhältst du die Anerkennung für die vier fertiggestellten Items (in Bezug auf die Geschwindigkeit für den Sprint) und wenn du die restlichen Aufgaben dafür beendest Fünfter Gegenstand in einem zukünftigen Sprint wird der volle Kredit für diesen Gegenstand erhalten. Aber hättest du mehr getan, wenn du Scrum nicht benutzt hättest? Der einzige Fehler in Scrum besteht darin, dass man nicht aus seinen Fehlern lernt, die gleichen dysfunktionalen Dinge wiederholt macht, während man andere Ergebnisse erwartet.

Also, in Ihrem Sprint Planning Meeting, verbringen Sie nicht viel Zeit damit, sich Gedanken über etwas zu machen, das Sie nicht wissen können. Lassen Sie das Team über die Arbeit nachdenken und lassen Sie sich dann für den Umfang der Arbeit anmelden, die sie während des Sprints als angenehm empfinden. Wenn sie zu wenig beitragen, können Sie immer etwas in den Rückstand ziehen oder den Sprint vorzeitig beenden.Wenn sie zu viel Commit ausführen, beenden Sie die Backlog-Elemente in der Reihenfolge der Priorität und diskutieren, warum die nicht beendeten Elemente in der Sprint-Retrospektive nicht abgeschlossen werden konnten und wie Sie verhindern können, dass in zukünftigen Sprints unfertige Elemente vorhanden sind.

Übrigens, ich weiß, das war wahrscheinlich eine schlechte Wortwahl Ihrerseits, aber ein effektiver Scrum Master läuft nicht im Sprint. Das Team leitet den Sprint und der Scrum Master sucht aktiv nach Hindernissen, die ihre Produktivität verringern und ihre Fähigkeit beeinträchtigen, ihre Verpflichtungen zu erfüllen. Scrum Masters sind keine Manager, sie sind eine Kombination aus Schiedsrichter, Trainer und Anschreiber. Sie sind der Bewahrer des Prozesses, sie helfen dem Team, den Prozess zu verfolgen, sie schützen das Team vor externen Agenten, die versuchen, den Prozess zu umgehen und verfolgen den Fortschritt während des Sprints, indem sie sicherstellen, dass das Sprint-Backlog aktualisiert wird und das Sprint-Burndown-Diagramm spiegelt die Realität täglich wider. In der von Ihnen beschriebenen Situation, in der sich das Team nicht sicher ist, wie viel Arbeit sie sich anmel- den sollten, sollte der Scrum Master das Team entscheiden lassen, dass Respekt für die Teamverantwortung der Verpflichtung besteht. Was auch immer die Entscheidung ist, es wird nicht falsch sein.

Answer 10

Spikes sollten in Zeitform verpackt werden. Es übt Druck auf das Team aus, den Umfang zu begrenzen und eine bessere Vorstellung von den Kosten zu haben, die die Forschung mit sich bringt; dh es ist nutzlos, 3 Tage Forschung für eine Aufgabe durchzuführen, die ein paar Dollar kosten würde.

Dies wird auch durch Lathams Arbeit zur Zielsetzungstheorie unterstützt, in der er dieses Problem gezielt anpackt.