Wo sollte ich offene Punkte aus früheren Sprints nachverfolgen?

Ich denke, Sie haben den richtigen Ort. dh der Rückstand. Aber nur, wenn Sie sie tatsächlich tun werden und sie an der Spitze stehen sollten!

Wenn Sie sie nicht tun werden, schlage ich vor, eine Säule/Tag/Tafel für Müllhalden „wird nicht repariert“ oder „Phase 2“ zu verwenden, aber machen Sie sich nichts vor, dass sie irgendwie aufgegriffen und auf magische Weise erledigt werden, ohne Zeit in Anspruch zu nehmen Sie möchten andere Funktionen ausführen

TL;DR: Ganz oben im Product Backlog.

Klingt wie Ihre Aufgaben sind nicht DoneDone . Schließen Sie die Feature-Produktion vollständig ab und bereiten Sie sie vor, bevor Sie mit neuen Features beginnen.

Sie möchten später keine Zeit reservieren, um es fertig für die Veröffentlichung zu machen, denn wie viel Zeit Sie benötigen, ist ungewiss, aber der wichtigere Kontextwechsel ist teuer. Das spätere Beheben oder Beenden von Aufgaben wird viel mehr Zeit in Anspruch nehmen als jetzt, da alles noch frisch im Gedächtnis ist.

Umgang mit Mängeln

Ich schlage vor, dass Sie eine Null-Fehler-Richtlinie implementieren , siehe diese Antwort für weitere Details: https://pm.stackexchange.com/a/19805/8528

Produktbereitschaft fördern :

Es gibt ein Sprichwort in XP , dass die Produktion am ersten Tag des Projekts beginnt. Vom ersten Tag an, an dem Sie eine Codezeile schreiben, behandeln Sie das Projekt so, als ob es in Produktion wäre, und danach nehmen Sie nur noch Änderungen an einem Live-System vor.

Es ist ein grundlegender Unterschied, wie Sie Ihren Code sehen. Anstatt Produktion und Bereitstellung als ein Ereignis in ferner Zukunft zu betrachten, stellen Sie sich vor, dass Sie und Ihr Team heute in der Produktion sind, und fangen an, sich entsprechend zu verhalten.

Dies hat folgende Vorteile:

• Das Team respektiert die Codebasis – was zu höherer Qualität führt.
• Es ist einfacher, Änderungen vorzunehmen – als Ergebnis eines gut umgestalteten Codes.
• Der Eigentümerstolz steigt – weil das Team Qualitätsarbeit leistet.
• Sie können jederzeit freigeben – das ist der einzige Zeitpunkt, an dem wir Mehrwert schaffen.

Wie kann ich offene Fehler/Aufgaben aus früheren Sprints getrennt von Produkt-Backlog-Einträgen im Zusammenhang mit neuen Funktionen verfolgen?

Du solltest es gar nicht erst versuchen! Einer der Zwecke des Product Backlogs besteht darin, als Parkplatz für projektbezogene Dinge zu dienen, die während des Projektlebenszyklus möglicherweise nie erreicht werden, die aber erfasst werden sollten.

Indem Sie die Informationen aufbewahren, vermeiden Sie die Eingabe von Duplikaten und können auch Schätzungen der Projektlaufzeit mit oder ohne Funktionen auf Ihrem Parkplatz abgeben. Dies kann bis zu einem gewissen Punkt für die Projektplanung nützlich sein.

Sie sollten im Allgemeinen nur feinkörnige Geschichten für ein oder zwei Sprints im Voraus priorisieren. Der Rest Ihres Backlogs sollte als YAGNI-Items in Ruhe gelassen werden, bis sie tatsächlich benötigt werden.

Wenn Sie andererseits Dinge haben, von denen Sie wissen, dass sie niemals erledigt werden, egal wie lange das Projekt läuft, sollten Sie sie einfach als Unordnung entsorgen. Wenn die Probleme wichtig sind, werden sie vom Team oder den Stakeholdern erneut angesprochen; andernfalls, wenn sich niemand um diese bestimmten Product Backlog Items kümmert, warum sollte man sie dann weiter verfolgen?

Wenn Sie sich einfach nicht dazu bringen können, etwas zu verwerfen, auch wenn es Ihnen Reibung in Ihrem Prozess verursacht, dann archivieren Sie die Elemente. Wenn Sie Trello verwenden, archivieren Sie die Karten oder verschieben Sie sie in eine Parkplatzliste. Wenn Sie Excel verwenden, verschieben Sie die Elemente nach parking_lot.xlsx . Wenn Sie etwas anderes verwenden, erhalten Sie die allgemeine Idee: Elemente, die nie fertig sind, aber nicht weggeworfen werden, werden dort abgelegt, wo sie während des Backlog Refinement oder der Sprintplanung nicht eingesehen werden müssen.

Meine persönliche Faustregel lautet: Wenn eine User Story den Status „Das schaffen wir nie“ erreicht, werfe ich sie weg. Das „vielleicht irgendwann“-Zeug setzt sich einfach am Ende des Product Backlogs ab, wie Sedimente in einem Teich.

Bugs sollten nicht getrennt von den anderen Aufgaben in einem Backlog aufbewahrt werden. Wenn dies der Fall ist, wie wird der Product Owner (ich gehe davon aus, dass Sie, da Sie „Sprints“ erwähnt haben, Scrum durchführen) diese priorisieren? Wenn Sie Folgendes in Bezug auf das Wichtigste bis zum Unwichtigsten haben:
Geschichte A, Fehler/Aufgabe 1, Geschichte B, Fehler/Aufgabe 2
Wie um alles in der Welt wollen Sie das bedeuten, während Sie Geschichten und Fehler an getrennten Orten aufbewahren ?

Abgesehen davon können Sie einen Weg finden, Bugs getrennt von Storys abzugrenzen - viele Issue-Tracking-Systeme haben diese Funktionalität eingebaut, sodass Sie sie einfach filtern können, um nur das anzuzeigen, was Sie gerade interessiert. Andernfalls (wenn Sie beispielsweise Microsoft Word oder sogar nur ein paar bedruckte Zettel verwenden (bitte nein)), können Sie sie einfach mit einer anderen Farbe markieren.

" Dinge, die das Team später tun wird " (TTWDL) ... Fehler/ Aufgaben aus früheren Sprints. . . . offene Punkte aus vorherigen Sprints.

Ich interessiere mich für diese Artikel.

Wenn es sich um neue Aufgaben handelt, zu denen Sie einfach nicht gekommen sind (z. B. weil Sie den Sprint so verschoben haben, dass er innerhalb der Timebox fertig ist), dann gehen sie definitiv zurück in das Produkt-Backlog, um später neu priorisiert zu werden.

Wenn es sich um Gegenstände handelt, die gegen Ihre Akzeptanzkriterien verstoßen haben, nenne ich diese Pfandrechte. Ich habe sie zurück in das Produkt-Backlog gestellt, aber entsprechend gekennzeichnet, damit der Status sichtbar ist, wenn wir Prioritäten setzen.

Wenn es sich um Bereinigungsaufgaben handelt, um die Codequalität auf den Produktionsstandard zu bringen, nachdem Sie eine erste Implementierung haben, dann frage ich mich als Erstes: Was ist Ihre Definition of Done? Enthält es Elemente der Produktionsqualität (Tests, Dokumentation, Antworten auf Code-Review-Elemente usw.)? Wenn nicht, dann sollte es, und Sie müssen dies berücksichtigen, wenn Sie berechnen, wie viel Umfang Sie in Ihrer Timebox erledigen können (oder umgekehrt).

Abgesehen davon neigt mein Team dazu, solche Dinge auf den Haufen technischer Schulden zu legen, mit dem Verständnis, dass sie zwischen den Sprints oder nach Möglichkeit bearbeitet werden, und der Erwartung, dass wir manchmal einen Sprint durchführen, dessen Ziel es ist, die technischen Schulden zu reduzieren .

Wenn es Dinge sind, die während des Sprints als zusätzliche gute Ideen aufgetaucht sind, definitiv das Product Backlog.

Wenn es sich um Fehler handelt, die nach Abschluss des Sprints entdeckt wurden, haben Sie möglicherweise einen separaten Prozess zur Behandlung von Fehlern. Wenn Sie dies nicht tun, setzen Sie sie in den Rückstand, gekennzeichnet als Fehler und/oder bekannte Probleme, damit dies bei der Priorisierung sichtbar ist. Vielleicht haben Sie irgendwann einen Sprint, dessen Ziel "Squash Bugs" ist.