Wer kann das WIP-Limit in DoW ändern, wenn dringende Arbeit entsteht?

Es gibt keinen eindeutigen Hinweis darauf, dass diese Frage nur zum Sprint Backlog gehört.

Ich glaube, das ist falsch.

Die Dringlichkeit der Arbeit impliziert für mich, dass sie nicht bis zum nächsten Sprint warten kann. Das Team muss diese Arbeit in den aktuellen Sprint einbringen und ist daher dafür verantwortlich, die Entscheidung über die Erhöhung der WIP-Limits zu treffen. Da das Entwicklungsteam den Sprint-Workflow besitzt, glaube ich, dass sie diejenigen sind, die bestimmen, ob das WIP-Limit (vorübergehend) erhöht werden sollte oder ob sie einen Weg finden sollten, Arbeit aus dem Sprint zu entfernen. Wenn Arbeit aus dem Sprint entfernt wird, müssen sie möglicherweise mit dem Product Owner zusammenarbeiten, wenn das Sprint-Ziel gefährdet ist.

Update: Diese Antwort geht fälschlicherweise davon aus, dass das OP mit WIP die Sprint-Kapazität meinte (eine Grenze, wie viel Arbeit in einen Sprint aufgenommen werden kann), nicht Kanban-WIP-Grenzen (eine Grenze, wie viel Arbeit in einem einzelnen Status zu einem Zeitpunkt vorhanden sein kann). Zeit). Ich überlasse es der Nachwelt, aber es beantwortet diese Frage nicht.

---

Ich würde argumentieren, dass die einzig gültige Antwort lautet:

Niemand, da Arbeit mit „hoher Priorität“ kein triftiger Grund für die Änderung des WIP während des Sprints ist.

Die Sprint-Kapazität gibt an, wie viel Arbeit das Entwicklungsteam zu leisten glaubt . Arbeit mit hoher Priorität ist kein triftiger Grund, diesen Betrag zu erhöhen . Auch wenn Sie wirklich zwei Kinder zur Welt bringen müssen, kann sich eine schwangere Mutter nicht plötzlich für Zwillinge entscheiden.

Wenn die Arbeit jetzt wirklich erledigt werden muss , dann haben Sie zwei Möglichkeiten:

1. Bauen Sie Pufferzeit in Ihre Sprints ein, damit die Kapazität vorübergehend erhöht werden kann, ohne eine dauerhafte Änderung vorzunehmen
2. Nehmen Sie etwas aus dem Sprint heraus , damit die Kapazität erhalten bleibt.

Meine andere Antwort beantwortet eine andere Frage, die das OP geklärt hat, nicht das, was gestellt werden sollte. Ich überlasse es der Nachwelt. Diese Antwort befasst sich mit der Änderung der Kanban-WIP-Limits während eines Sprints.

---

In diesem Fall würde ich argumentieren, dass die beste Antwort nicht wirklich aufgeführt ist. Dieses Problem hat zwei Aspekte.

1. Was ist mit dieser speziellen Arbeit mit hoher Priorität zu tun, die hereinkommt, wenn das Team das WIP-Limit erreicht hat?
2. Was tun, um das WIP-Limit dauerhaft zu erhöhen?

Erstens gibt es bereits Fragen zu pmse, die sich damit befassen, daher werde ich hier nicht darauf eingehen. Die kurze Antwort lautet: „es kommt darauf an“. Was ich persönlich (wahrscheinlich) tun würde, ist das WIP-Limit einfach zu ignorieren.

Zum anderen bietet Scrum dafür ein ideales Werkzeug. Die Sprint-Retrospektive . Während der Retro kann das Team besprechen, was passiert ist und ob das WIP-Limit erhöht werden soll oder nicht.

Also, ich denke, ich würde antworten:

Niemand, da WIP-Limit [ kann nicht sollte nicht] im Sprint geändert werden

Meine Antwort wäre

Niemand, da Arbeit mit „hoher Priorität“ kein triftiger Grund für die Änderung des WIP während des Sprints ist.

Das WIP-Limit, also die Anzahl der Tickets, die sich in einem bestimmten Entwicklungsstatus befinden können (eine Spalte auf dem Board), wird nicht durch die Dringlichkeit der Arbeit bestimmt, sondern durch den Arbeitsumfang, an dem das Team derzeit arbeiten kann gleichzeitig, ohne dass es zu Ineffizienzen kommt.

Stattdessen sollte das Team, wenn sehr dringende Arbeit zum Rückstand des Sprints hinzugefügt wird, einen Plan entwickeln, um innerhalb der aktuellen WIP-Grenzen etwas Platz freizugeben, um so schnell wie möglich mit der Arbeit an der dringenden Arbeit zu beginnen. Die beiden wahrscheinlichen Aktionen sind

• Beschleunigen Sie die Arbeit an einem fast abgeschlossenen Arbeitselement, damit es etwas schneller zu „Fertig“ wechseln kann
• Verschieben Sie ein Arbeitselement zurück von „In Bearbeitung“ nach „Nicht begonnen/Wird nicht bearbeitet“. Vorzugsweise sollte dies ein Arbeitselement sein, an dem sehr wenig gearbeitet wurde, damit möglichst wenig Arbeit „verloren“ geht.

Wenn keine Aktion möglich ist, können Sie die WIP-Limits vorübergehend ignorieren, aber entweder führt dies zu Ineffizienzen aufgrund von Kontextwechseln oder einige Arbeitselemente werden effektiv in den Status „Wird nicht bearbeitet“ versetzt, ohne dass dies auf dem Board widergespiegelt wird .