In unserem agilen Team stoßen wir häufig auf das Problem, dass der Scrum Master darauf hinweist, dass alle unsere Stories vor einer Iteration vollständig mit Aufgaben versehen und geschätzt werden sollten, und sobald diese Aufgaben hinzugefügt wurden, können während der Iteration keine weiteren Aufgaben/Storys mehr hinzugefügt werden. Meiner Meinung nach ist dies sehr schwierig zu bewerkstelligen, wenn der Arbeitsgegenstand nicht vollständig verstanden wird. Meiner Erfahrung nach ist der Versuch, eine Geschichte vollständig zu bearbeiten, bevor man tatsächlich daran arbeitet, schwierig, weil:
Ich weiß nicht, was die Aufgaben tatsächlich beinhalten werden, bis ich mich mit dem Code in diesem bestimmten Bereich vertraut gemacht habe.
Selbst wenn ich mich damit vertraut mache, werde ich ständig Dokumente usw. lesen, um mein Verständnis zu verbessern und nach Effizienz zu suchen, wodurch möglicherweise meine ursprünglichen Aufgaben überflüssig werden.
Vielleicht ist das nicht sehr agil von mir, aber es scheint die beste Methode zu sein, um der geleisteten Arbeit einen Mehrwert zu verleihen. Bin ich einfach zu starr oder gibt es einen gemeinsamen Ansatz, um dieses Problem zu lösen? Tritt dieses Problem häufig bei Benutzern dieser Website auf, da es bei Entwicklern, mit denen ich gearbeitet habe, ziemlich häufig vorkommt?
Wann füge ich Aufgaben zu Stories hinzu und wie schätze ich Aufgaben?
Sie sollten Aufgaben zum Zeitpunkt der Iterationsplanung hinzufügen. Das Entwicklerteam sollte einen Spielplan haben, wie die Geschichte zu Ende geführt werden kann. Meiner Erfahrung nach hat es sich als hilfreich erwiesen, die Aufgaben in Stunden zu schätzen. Es sollte jedoch klar sein, dass die Stunden nur der internen Teamkoordination dienen und nicht dem Management als Grundlage für die Leistungsmessung dienen.
Unser Scrum Master weist darauf hin, dass alle unsere Stories vor einer Iteration vollständig ausgearbeitet und geschätzt werden sollten.
Ich stimme Ihrem Scrum Master zu, dass dies vor Beginn der Iteration geschehen sollte. Dies ist das Hauptziel des Iterationsplanungsmeetings.
Während der Iteration können keine weiteren Storys hinzugefügt werden.
Da stimme ich Ihrem Scrum Master zu. Das ist die Grundvoraussetzung von Scrum.
Während der Iteration können keine weiteren Aufgaben hinzugefügt werden.
Ich stimme Ihrem Scrum Master in Bezug auf den Teil „keine weiteren Aufgaben“ nicht zu. Dies ist die Denkweise des Wasserfalls (vorausschauende Planung). Die Prämisse von Scrum (adaptive Planung) ist, dass die Softwareentwicklung teilweise F&E-Arbeit ist. Sie sollten mit einem bestimmten Ansatz beginnen, um die Geschichte nach bestem Wissen und Gewissen zu erzählen. Wenn Sie jedoch auf Probleme stoßen, kann eine Aufgabe länger dauern als ursprünglich angenommen. In einigen Fällen funktioniert Ihr anfänglicher Ansatz möglicherweise überhaupt nicht und Sie müssen möglicherweise einen anderen Ansatz ausprobieren. An diesem Punkt können Sie die Aufgaben neu schätzen oder wiederholen.
Wenn ein hohes Maß an Unsicherheit besteht, bitte ich meine Teams, in der vorherigen Iteration eine zeitgesteuerte Forschungsgeschichte (Spike) zu erstellen. Dies kann die Durchführung eines Proof-of-Concept beinhalten, um einen Ansatz zu validieren. Dann ist die Verpflichtung des Teams, das zu erreichen, wofür es sich verpflichtet hat, viel fester.
Selbst wenn ich mich damit vertraut mache, werde ich ständig Dokumente usw. lesen, um mein Verständnis zu verbessern und nach Effizienz zu suchen, wodurch möglicherweise meine ursprünglichen Aufgaben überflüssig werden.
Das klingt zu zaghaft. Sie sollten die Anforderungen gut verstehen und einen Ansatz geplant haben, wenn Sie im Iterationsplanungsmeeting eine Teamzusage machen.
Die häufigsten Gründe, warum Menschen Schwierigkeiten haben, zu schätzen, die ich gesehen habe, sind:
Du versuchst, zu genau zu sein
Es kann hilfreich sein, einige Geschichten, die Sie zuvor gemacht haben, zur Verfügung zu haben, wenn Sie sie als Benchmarks verwenden möchten.
Wenn Sie ein Beispiel für eine 2-, 5-, 8- und 13-Punkte-Geschichte haben, bringen Sie sie zu Ihrer Schätzungssitzung mit. Hoffentlich ist es einfacher, nach dem Motto "es ist definitiv größer als die 2-Punkte-Geschichte und kleiner als die 13-Punkte-Geschichte" einzuschätzen. In diesem Fall ist es entweder eine 5 oder eine 8, wählen Sie, was Ihnen am nächsten kommt.
Denken Sie daran, dass der Zweck der Schätzung nicht die Genauigkeit ist. Sie werden manchmal zu groß und bei anderen Gelegenheiten zu klein, alles gleicht sich mit der Zeit aus.
Unzureichende Akzeptanzkriterien
Wenn die Akzeptanzkriterien keine wichtigen Informationen enthalten, ist die Schätzung schwierig. Zu beachten sind Formulierungen wie „Aktuelles Verhalten replizieren“. Wenn Sie das aktuelle Verhalten nicht kennen, wird es wirklich schwierig, sich eine Vorstellung davon zu machen, wie groß die Geschichte sein wird!
Bitten Sie Ihren Product Owner/Business Analyst um Klärung, bevor Sie die Geschichte akzeptieren!
Ihre Geschichten sind zu groß
Um das Beispiel zu verwenden, das Daniel in seiner Antwort gibt:
Als Benutzer möchte ich, dass meine Schlussrechnung alle mir zur Verfügung stehenden Rabatte berücksichtigt.
Versuchen Sie, die Geschichte in kleinere Stücke aufzuteilen. Vielleicht:
Als Frühabonnent möchte ich, dass meine Schlussrechnung meinen Frühbucherrabatt berücksichtigt.
Als Mitarbeiter möchte ich, dass meine Schlussrechnung meinen Personalrabatt berücksichtigt.
Als Inhaber einer Treuekarte möchte ich, dass meine Schlussrechnung meinen Treuekartenrabatt berücksichtigt.
etc.....
Kleinere Geschichten sind im Allgemeinen leichter zu verstehen und erfordern weniger wahrscheinlich mehrere Systeme usw.
Es gibt große Unbekannte
Vielleicht haben Sie noch nie an diesem Code gearbeitet. Vielleicht bauen Sie etwas, das sich von allem unterscheidet, womit Sie Erfahrung haben. Möglicherweise verwenden Sie ein neues Tool eines Drittanbieters und haben keine Ahnung, wie es funktioniert. Diese Art von Zeug macht eine Schätzung ziemlich unmöglich, da Sie nur sehr wenig haben, auf das Sie eine Zahl stützen können.
In diesem Szenario ist es eine gute Idee, einen Spike durchzuführen , um das vorliegende Problem besser zu verstehen.
Ich habe es immer aus dieser Sicht genommen:
Wenn Sie die Story nicht ausführen können, weil Sie nicht wissen, welche Aufgaben erledigt werden müssen, woher wissen Sie dann, wie groß die Story ist, um sie einzuschätzen, und wie können Sie sich dazu verpflichten, sie zu erledigen?
In diesen Situationen (und sie kommen sehr häufig vor) bedeutet dies normalerweise, dass eine Geschichte entweder zu weit gefasst ist (es ist nicht so, dass Sie nicht alle Schritte kennen, es sind einfach zu viele, um sie praktisch aufzuzählen) oder zu vage.
Nehmen wir als Beispiel an, ich habe diese Geschichte:
Als Benutzer möchte ich, dass meine Schlussrechnung alle mir zur Verfügung stehenden Rabatte berücksichtigt.
Das kann ein einzelnes Feld sein oder es kann auf 10 verschiedene Systeme verteilt sein, von denen 2 in Excel sind. An diesem Punkt bin ich auf eine Menge Reibungen gestoßen, weil die Leute sich vorstellen, was eine lieferbare Geschichte ist. Ich würde Ihnen sagen, dass Sie eine Forschungsgeschichte mit einem konkreten Ergebnis haben sollten wie:
Als Account Manager möchte ich alle möglichen Rabattquellen identifizieren.
Ich habe Leute davor zurückschrecken lassen, weil es per se keine Feature-Bereitstellung ist. Diese Leute würden sagen, dass es die Aufgabe des Unternehmens ist, dies zu bestimmen und bereitzustellen, aber oft sind dies sehr technische Fragen, weil der Account Manager alles an ein oder zwei Stellen sehen kann, aber es ist wirklich in einer Reihe von Datenbanken. Ich persönlich denke, dass es sich lohnt, ein bisschen agil zu sein, um die Arbeit richtig zu erledigen, aber vielleicht können andere eine Alternative anbieten.
Das andere wirklich große Problem dabei ist, dass, wenn Sie diese Geschichte übernehmen und den Rest des verfügbaren Aufwands im Sprint mit anderen Geschichten füllen, die tatsächliche Implementierung von Code auf der Grundlage Ihrer Erkenntnisse bis zum nächsten Sprint warten muss. Dafür gibt es eine ziemlich einfache Lösung. Lassen Sie in Ihrem Sprint Platz für weitere Geschichten. Wenn Ihre Geschwindigkeit 60 Punkte beträgt, legen Sie sich nur auf 45 fest. Das kann Ihnen den Raum geben, mehr Geschichten zu erstellen und einzubeziehen, um Ihre Lösung zu implementieren. Auch hier befinden wir uns in der Grauzone von Agile, aber ich denke, es geht darum, die Arbeit zu erledigen und die Absicht hinter diesen Agile-Regeln einzuhalten.
Hoffe das hilft!
Ben
Daniel
Ben