Wie kann man unbestimmbare Aufgaben in einem Scrum Sprint bearbeiten? [geschlossen]

Ich bin mir nicht sicher, was der Begriff in Scrum ist, aber in der User Story-Terminologie würdest du einen "Spike" machen, was im Grunde eine sehr kurze Zeit der Erforschung des Themas ist, damit dein Team abschätzen kann Aufgabe am Ende der Spitze.

Beispiel:

  

Geschichte:

     

Der Analyst möchte prüfen können   Finanzdaten in Tortendiagrammen.

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 zu entscheiden, welche Route Sie nehmen sollen.

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" (ja, das ist der in Scrum verwendete Begriff) reservieren, um Geschäftsdomänenprobleme zu lösen, die keine bekannte Lösung haben. Nicht für das Team, um Training zu machen.

Wenn Sie wirklich Nachforschungen anstellen müssen, um einen guten Kostenvoranschlag zu erhalten, könnten Sie die Recherche selbst als Aufgabe durchführen oder sie vor der Sprint-Planung beiseite legen und erledigen lassen (von jemandem).

Im Allgemeinen denke ich, dass wenn Sie keine gute Schätzung erhalten, Sie entweder mit einer schlechten Schätzung gehen sollten (dh eine wilde Schätzung), oder Sie sollten die Aufgabe zeitlich packen, so dass Sie einen festen Zeitraum reservieren dafür in einem Sprint. Danach haben Sie entweder eine fertige Lösung, oder Sie haben eine bessere Unterstreichung davon, so dass Sie es abschätzen oder in Teilaufgaben für den nächsten Sprint (oder einen späteren Sprint) zerlegen können.

Meinst du wirklich Aufgaben oder redest du ü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 & amp; D. Bedenken Sie, dass bei Scrum alles Timebox ist.

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

Wenn die Aufgaben unschätzbar erscheinen, wäre es meiner Meinung nach am besten, diese Aufgaben in kleinere Aufgaben aufzuschlüsseln, die Sie einschä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 Artikel .

Teilen Sie die unbestimmbare 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 den Beginn des Sprints für eine Woche Spike.

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 als wäre eine andere Option, den Spike in Sprint 1 und die Aufgaben in Sprint 2 zu machen. Der Nachteil ist, dass es so aussieht, als ob der Prozess einen unnatürlichen Zusammenbruch der Arbeit erzwingt. Warum diese Woche entdecken und dann eine Weile warten, bevor Sie mit der Arbeit beginnen.

Für solche Aufgaben verwenden wir "Kontingente" oder einen spezifischen Rückstand. Das Scrum Tool Agilo unterstützt diese Arbeitsweise und berechnet auch diese Probleme, z. im Burndown. Auf diese Weise erhalten Sie eine gute Kontrolle über die "nicht planbaren" Elemente.

Verwechseln Sie Präzision mit Genauigkeit?

Die Idee hinter der agilen Schätzung besteht darin, eine Zahl zu finden, 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 Rückstandsobjekt 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 ist meistens fertig, bekommst du die vier fertiggestellten Items gutgeschrieben (in Bezug auf die Geschwindigkeit für den Sprint), und wenn du die restlichen Aufgaben dafür erledigt hast 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.

Machen Sie sich also in Ihrem Sprint-Planungs-Meeting nicht viel Gedanken über etwas, 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 übernehmen, schließen Sie die Backlog-Elemente in der Reihenfolge der Priorität ab und diskutieren, warum die unfertigen Elemente in der Sprint-Retrospektive nicht fertiggestellt 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.

Spikes sollten zeitlich begrenzt sein. 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 sinnlos, 3 Tage Forschung für eine Aufgabe zu erledigen, die ein paar Dollar kosten würde.

Dies wird auch durch Lathams Arbeit zur Zielsetzungstheorie unterstützt, in der er sich speziell diesem Problem widmet.