Wie gehe ich mit wiederkehrenden Aufgaben in einem Sprint um?

Wir arbeiten an einem Softwareprodukt, das mittlerweile ca. 40% unserer Kapazitätserhaltungsarbeiten wie z. B. manuelles Prüfen von Daten pro Tag in Anspruch nimmt. Was wäre der empfohlene Weg zum Umgang mit diesen Aufgaben innerhalb eines Scrum-Frameworks?

Momentan sehe ich 3 Lösungen:

Verschieben Sie sie aus dem Sprint/Backlog, da Scrum Backlog Items (SBIs) einmalige Probleme sein sollten, und reduzieren Sie die Kapazität des Teams entsprechend. Was zu einer Intransparenz der zu erledigenden Aufgaben führen würde (um unser Produkt am Leben zu erhalten)

Behandeln Sie sie wie normale SBIs und halten Sie sie in den Sprints. Eine pro Tag, was zu einem unübersichtlichen Rückstand führt, und während des Sprintwechsels müssen die PBIs ebenfalls durchgeführt werden, spiegeln sich jedoch nicht in den Statistiken/Planungen wider. Versuchen Sie, diese Aufgaben zu automatisieren und die Menge in Zukunft zu reduzieren.

Erstellen Sie einen SBI mit einer Checkliste und einer zu überprüfenden Zeile/Checkbox pro Tag. Dies würde dazu führen, dass man permanent in Arbeit ist und zugehörige Story Points das Burn-Down-Chart erst ganz am Ende des Sprints reduzieren.

Was meint ihr und kennt ihr aus Erfahrung eine Lösung die funktionieren würde?

Wenn ein so hoher Prozentsatz Ihrer Arbeit Wartung/Support ist, wäre ein Kanban-Ansatz vielleicht besser geeignet? Abgesehen davon klingt es nach einer schrecklichen Zeitverschwendung, 40 % Ihrer Zeit als Team damit zu verbringen, Daten manuell zu überprüfen.

Antworten (2)

Ein gemeinsames Thema bei agilen Methoden ist die Kommunikation, Sichtbarkeit und Transparenz der geleisteten Arbeit und des Status dieser Arbeit, um sicherzustellen, dass die richtigen Stakeholder Zugriff auf diese Informationen haben.

Ohne alle Details über diese Arbeit zu kennen, scheint das Product Backlog nicht der richtige Ort dafür zu sein. Der Scrum Guide definiert das Product Backlog als „eine geordnete Liste von allem, was bekanntermaßen im Produkt benötigt wird“. Sofern diese Arbeit nicht etwas darstellt, das das Produkt benötigt, würde ich einfach sicherstellen, dass die Arbeit während der Sprintplanung in das Sprint Backlog gestellt wird. Dies kann dem Team dabei helfen sicherzustellen, dass es es bei der Ausarbeitung des Sprint-Ziels und der Auswahl von Product-Backlog-Einträgen für den Sprint berücksichtigt. Ich würde jede Aufgabe als separates Element in das Sprint Backlog stellen und sie sogar so schätzen, wie Sie es mit anderen Arbeiten tun würden, um die Auswirkungen dieser notwendigen Arbeit auf die Fähigkeit zeigen zu können, andere Arbeiten für das Produkt zu liefern.

Langfristig scheint es jedoch so, als ob regelmäßige Arbeit, die 40 % der Kapazität beansprucht, angegangen werden sollte. Ich würde fragen, ob ein Entwicklungsteam die Leute repräsentiert, die diese Arbeit machen sollten. Alternativ würde ich gerne wissen, ob es Möglichkeiten gibt, den Prozess bis zu einem gewissen Grad zu automatisieren, damit die Belastung verringert werden kann, insbesondere wenn es sich um einen laufenden Prozess handelt.

Wie gehe ich mit wiederkehrenden Aufgaben in einem Sprint um?

Es hängt wirklich davon ab, welche Art von Arbeit in diesen wiederkehrenden Aufgaben ausgeführt wird.

Wenn es bei der Arbeit um das Beheben von Fehlern für die Anwendung, das Hinzufügen neuer Funktionen, jede Art von Produktverbesserungen oder Arbeiten geht, die ein Produktinkrement erstellen und ein Ziel für Sprints sein können, dann gehört es in Ihren Sprint und in Ihr Backlog und Sie erledigen es genau wie jede andere Geschichte.

Wenn die Arbeit mehr auf der Seite des Benutzersupports liegt (manuelle Überprüfung von Daten, Überprüfung verschiedener Informationen zur Beantwortung von Benutzerfragen, Angebot von Support per Telefon/Chat/E-Mail usw.), dann sollte diese Arbeit wahrscheinlich am besten aus Ihren Sprints herausgezogen werden Ihr Rückstand. Ich habe mit Teams zusammengearbeitet, die in ähnlichen Umgebungen gearbeitet haben, und sie haben eine einfache und effektive Lösung gefunden:

  • sie zogen eine Person aus dem Sprint heraus und ließen sie an „Operationen“ arbeiten;
  • Für diese Aktivität wurden ein separates Kanban-Board und ein separates Backlog erstellt.
  • Um es für alle fair zu halten, war es in jedem Sprint ein anderer Entwickler, durch Rotation;
  • Dieser Entwickler würde nicht an der Entwicklungsarbeit im Sprint teilnehmen, könnte aber an der Sprintplanung, täglichen Meetings und Retrospektiven teilnehmen, um mit dem, was im Sprint passiert, in Kontakt zu bleiben, während er "Operationen" abwickelt.
  • Jede Arbeit, die sie außerhalb des Sprints erledigten, wurde im Kanban-Board aufgezeichnet. Wenn es sich ausschließlich um Support handelte, blieb es im Kanban-Board und im Kanban-Backlog. Wenn sich herausstellte, dass es etwas war, das das Produkt verbesserte, erstellten sie Backlog-Elemente im Scrum-Backlog und überließen es den anderen (dh wenn es Support war, erledigten sie die Arbeit. Wenn es sich um die Produktentwicklung handelte, warfen sie die Arbeit über den Haufen Zaun an das Scrum-Team, das es wie jedes andere Element in seiner Pipeline gehandhabt hat).

Dieser Ansatz hielt die Dinge in beiden Pipelines (Support und Entwicklung) in Bewegung und schützte das Scrum-Team vor Arbeiten, die wenig mit Verbesserungen des Produkts zu tun hatten. Die unterstützende Person war manchmal nicht voll ausgelastet, aber darum ging es nicht .

Wenn schließlich die sich wiederholende Arbeit automatisiert werden kann, dann tun Sie dies und lassen Sie eine Maschine die Arbeit erledigen.

Wie gehe ich mit wiederkehrenden Aufgaben in einem Sprint um?
AntwortenHierDatenschutz-Bestimmungen1y, 0v