Der Product Owner möchte verfolgen, wie viele Punkte während eines Sprints für Fehler ausgegeben werden. Dies kann einige Probleme aufwerfen, wie z.
Bewerten einer bereits erledigten Aufgabe. Überraschenderweise gibt es selbst dann manchmal Diskussionen und Meinungsverschiedenheiten.
Viele kleine Aufgaben mit 0 Punkten punkten, die am Ende tatsächlich etwas Sinnvolles ergeben (ein Haufen schneller Lösungen).
Zählen der für Fehler ausgegebenen Punkte als verfügbare Punkte für neue Funktionen im nächsten Sprint, zusammen mit neuen Fehlern, die schließlich auftauchen werden.
Ich stimme ihm zu, dass es wichtig ist, die dafür aufgewendete Zeit zu verfolgen, aber Punkte scheinen in diesem Fall nicht wirklich gut zu spielen. Was sind also die besten Ansätze und Praktiken in diesem Fall? Zählen Sie die Stunden, die für jeden einzelnen aufgewendet wurden?
Das erste, woran Sie denken sollten, ist, dass points != time ; Punkte sind eine relative Schätzung der Komplexität. Während Sie anhand der Länge des Sprints und der Geschwindigkeit ein Gefühl für die pro Punkt verbrachten Stunden bekommen könnten , ist dies nicht der Zweck.
Die Art und Weise, wie ich normalerweise mit der Sprint-Planung für eine Umgebung umgehe, in der Kunden unweigerlich Fehler in Bezug auf Software in der Produktion melden, besteht darin, anzunehmen , dass n Punkte pro Sprint für Fehler ausgegeben werden . Dies passt zu Mike Cohns Beispiel, in dem man eine Geschichte schreiben könnte wie „Als Benutzer möchte ich, dass mindestens 15 Fehler behoben werden“.
Die beste Situation ist, wenn der gemeldete Fehler keine sofortige Behebung rechtfertigt und Ihre Sprints kurz sind, sodass der „Fehler“ eigentlich nur als Story für den nächsten Sprint gezählt werden kann. Aber "am besten" und "üblich" sind nicht dasselbe ...
Ich würde wirklich versuchen, auf den Punkt zu bringen, was der Product Owner will – ist es eine Notwendigkeit zu sehen, dass Fehler behoben werden? Müssen Sie sehen, ob mehr Aufwand für Fehler als für Funktionen aufgewendet wird? -- und planen Sie dementsprechend, anstatt zu versuchen, eine völlig künstliche Antwort auf die Frage zu finden, "wie viele Punkte für Fehler ausgegeben werden".
Die meisten Teams geben keine Punkte für die Auflösung technischer Schulden. Die Sache ist, wenn Sie Punkte für die Behebung von Fehlern im Code anhängen, die bereits mit Story Points geschätzt wurden, weisen Sie Story Points für „Arbeit leisten“ und nicht für „Ergebnisse erzielen“ zu, was ein subtiler, aber wichtiger Unterschied sein kann.
Geschwindigkeits- und Story-Punkte sind eine Möglichkeit, um zu messen, wie schnell ein Team neue Arbeitsfunktionen in veröffentlichbaren Arbeitsschritten erstellen kann.
In einem Projekt kann dies dazu führen, dass die Geschwindigkeit eines Teams im Laufe der Zeit immer geringer wird, da die gesamte Zeit darauf verwendet wird, technische Schulden zu lösen. Das ist auf seltsame Weise gut, denn es zeigt, dass die aktuelle Codebasis in naher Zukunft keinen neuen Geschäftswert in Form neuer Funktionen liefern kann. Dies wird zu einer Neufassung führen, und die gewonnenen Erkenntnisse führen zu einer skalierbareren Architektur.
Nicht jede Art von Schmerz ist schlimm.
Sieht so aus, als ob Ihr Team zwei Rollen spielt:
Die Schätzungstechnik könnte für beide verwendet werden, Schätzungen des Scrum-Teams vor der Iteration, zur Unterstützung haben Sie eine 1-tägige Iteration anstelle von 2 Wochen.
Es ist schwer, Support-Aufgaben im Vergleich zu den üblichen US-Aufgaben einzuschätzen, sie sind viel kleiner. Sie vergleichen die USA nicht mit der Unterstützungsaufgabe, warum versuchen Sie das also in die entgegengesetzte Richtung?
Versuchen Sie, Support-Aufgaben gegen Support-Aufgaben einzuschätzen .
jcmeloni
eMgz