Wie entscheiden wir, was in jeden Sprint aufgenommen werden soll, wenn wir den Rückstand gepflegt haben und eine relativ klare Richtung haben, was kurz- und langfristig zu tun ist? Wer trifft diese Entscheidung?
Es scheint, als ob agile Methoden dem Team erlauben, Entscheidungen zu treffen, aber was passiert, wenn das Team zu sicher vorgeht und sich zu wenig verpflichtet ?
Schlaffheit ist wichtig, aber ein Übermaß an verschwenderischem Nichtstun ist es nicht. Wahre Führung besteht darin, den Unterschied zu erkennen.
Der Product Owner priorisiert das Product Backlog, aber nur das Entwicklungsteam darf Stories schätzen. Das Team verwendet diese Schätzungen zusammen mit ihrer geschätzten Geschwindigkeit, um zu bestimmen, wie viel Arbeit in jedem Sprint akzeptiert werden sollte.
Dies scheint nur ein Problem zu sein, wenn Sie eine enge Sichtweise einnehmen. Das Projekt hat Meilensteine, Veröffentlichungstermine und andere Ziele, die in regelmäßigen Abständen mit dem aktuellen Fortschritt verglichen werden können. Wenn das Team nicht auf Kurs ist, um die notwendigen Managementziele zu erreichen, dann ist dies gutes Material für organisatorische Dialoge und Teamrückblicke.
Bitte beachten Sie jedoch, dass es nicht dasselbe ist, einfach zu sagen, dass das Team zu wenig engagiert ist, wie tatsächlich ein Team zu haben, das über große Eimer ungenutzter Kapazität verfügt. Das Ziel von Scrum ist eine nachhaltige Entwicklung, die eine gewisse Prozessschwäche erfordert. Es liegt am Team und der Organisation, zu verstehen, wie viel Puffer notwendig ist und wie viel „Verschwendung“ (z. B. muri , muda oder mura ) im Lean-Sinn des Wortes ist.
Denken Sie daran, dass eine 100-prozentige Auslastung nicht das Ziel ist. Wenn das Team bereits mit seinem optimalen nachhaltigen Tempo arbeitet, müssen Sie möglicherweise die Erwartungen, Prozesse, Ressourcen oder den Umfang Ihres Projekts untersuchen, um andere Wege zu finden, um Ihre Systemeinschränkungen zu bewältigen.
Es scheint offensichtlich, dass Sie ein Vertrauensproblem mit Ihrem Team haben.
Sie können einem Team nicht sagen, dass es sich zu wenig verpflichtet, es sei denn, Sie sind mit seiner Kapazitätsplanung nicht einverstanden. Schätzen Sie die Sprintkapazität? Wenn Sie der Meinung sind, dass Ihre Teams mehr Punkte liefern können, können Sie dies sicherlich beim Planungstreffen argumentieren, aber Sie können nicht erwarten, dass die Meinung einer Person als die "richtige" Schätzung angesehen wird. Es ist eine Teamleistung.
Sie sind Teil des Teams und können mitreden.
Wenn Sie der Meinung sind, dass das Team ineffizient oder faul arbeitet, oder einfach konkrete Ideen haben, wie das Team seine Geschwindigkeit verbessern kann, ist der richtige Ort, um diese Vorschläge zu machen, eine Sprint-Retrospektive und sicherlich kein Planungsmeeting. Ich würde dafür sorgen, dass Retros stattfinden (falls noch nicht geschehen) und Ihre Zweifel an der Effizienz des Teams dort ausgeräumt werden.
Der Schlüssel, um diese Art von Problemen zu vermeiden, liegt darin, die Schätzungen richtig zu bestimmen. Eine Möglichkeit, vernünftige Schätzungen zu erhalten, besteht darin, Schätzungen von jedem Feldexperten einzuholen und zu begründen, warum er oder sie so denkt. Schätzen Sie danach unter Berücksichtigung aller Punkte einen Zeitrahmen im Konsens ab. Wenn es beispielsweise drei Mitglieder gibt, die sich um Webdienste kümmern, müssen alle drei Gründe für die Schätzung derselben Aufgabe erläutern. Unter Berücksichtigung der Ansichten jedes Mitglieds wird der Aufgabe einstimmig ein Zielzeitrahmen zugewiesen.
Mannschaft entscheidet. Der Product Owner kann dies nicht entscheiden. Der Product Owner priorisiert nur. Wie entscheidet das Team? Erstmal nur eine Vermutung/gesunder Menschenverstand. Zweites Mal (Sprint) Geschichte (20 %) + Schätzung (80 %). Dritte Geschichte (40 %) erraten (60 %). Und irgendwann entscheidet die Geschichte (90 %) und der gesunde Menschenverstand (10 %). Das ist das Beste, was Sie bekommen können.
Tipp: Halten Sie im Sprint-Planungsmeeting 1 zusätzliche User Story bereit, da sonst möglicherweise ein weiteres Team-Meeting erforderlich ist, um eine neue in den Sprint aufzunehmen (wenn das Team schneller fertig wird).
Meiner Meinung nach entscheiden die folgenden Faktoren, welche Geschichten in jedem Sprint enthalten sind.
Tatsächlich ist es die gemeinsame Entscheidung von PO und Entwicklungsteam, welche Stories in jeden Sprint aufgenommen werden.
Brett Maytom PST