Konzentrieren Sie sich auf das, was im Sprint Review "erledigt" wurde

Der Sprint Review ist in der Regel das am schwierigsten zu realisierende Ereignis. Hier treffen sich das Scrum-Team und seine Stakeholder, also die Veranstaltung mit der größten Teilnehmerzahl. Es ist auch das Ereignis, zu dem verschiedene Personen mit unterschiedlichen Zielen kommen.

• Das Entwicklungsteam ist anwesend, um seine Arbeit zu präsentieren und Feedback zu erhalten. Sie sind hoffentlich auch da, um mit ihren Interessengruppen in Kontakt zu treten.
• Der Product Owner ist ebenfalls für Feedback da, aber auch um die längerfristige Roadmap und den Stand des Product Backlogs zu überprüfen.
• Die Stakeholder kommen oft, um die Dinge zu sehen, die sie sich gewünscht haben. Wir bitten sie auch, ihre Erkenntnisse, die sie während des Sprints gesammelt haben, mit uns zu teilen und am Product Backlog mitzuarbeiten.

Eine Sache, die ich beobachtet habe, ist, dass der Fokus oft auf dem liegt , was geplant war und was jetzt "erledigt" ist. Ich halte das für ein falsches Verhaltensmuster. Fortschritte sind zwar wichtig, aber ich finde, der Schwerpunkt sollte auf dem liegen , was "erledigt" ist und was als nächstes zu tun ist.

Was ist so schlimm daran? Was war geplant und was ist jetzt "erledigt"?

Eine berechtigte Frage. Ist es wichtig, was geplant war? Man könnte behaupten, dass es wichtig ist. Aber es gibt nichts, was man jetzt noch tun könnte. Es war zwar geplant, aber es war nicht "erledigt" und kann nicht geliefert werden. Die Untersuchung dieser Frage kann dem Scrum-Team zwar Möglichkeiten zur Verbesserung bieten, aber das ist kein Thema für den Review, sondern für die Retrospektive. Der Zweck des Rückblicks ist der Blick nach vorne, nicht der Blick zurück.

1. Sie konzentriert sich auf das Sprint Backlog, den kurzfristigen Plan.
2. Das bestärkt uns in dem Glauben, dass unsere Arbeit unendlich vorhersehbar ist.
3. Ignoriert den Hauptzweck der Sprint Review, nämlich zu prüfen, was als nächstes zu tun ist.

Anstatt sich speziell auf das zu konzentrieren, was nicht "erledigt" wurde, sollten wir uns stattdessen ansehen, was das für die Zukunft bedeutet.

• Wenn wir uns das Inkrement und das Product Backlog ansehen, welche Anpassungen müssen wir vornehmen?
• Gibt es offensichtliche Hindernisse, die die Stakeholder mitnehmen könnten?
• Gibt es neue Erkenntnisse, die unsere Meinung ändern könnten?

Diese Fragen erlauben es uns, einen Schritt weiter zu gehen.

Alternative: Was ist jetzt "erledigt" und was ist als nächstes zu tun?

Können wir, anstatt eine Liste der geplanten und eine Liste der erbrachten Leistungen vorzulegen, dasselbe Ergebnis erzielen, uns aber auf die Zukunft konzentrieren? Zwei Wege, die ich für gut befunden habe, sind:

Schauen wir uns das Backlog jetzt und vor einem Sprint an

Bei dieser Option zeigt das Team das Backlog, wie es zu Beginn des Sprints war und wie es jetzt aussieht. Diese Vorgehensweise hat einige Vorteile:

1. Der Schwerpunkt liegt auf dem Product Backlog und darauf, was als nächstes zu tun ist.
2. Der Product Owner kann über die Punkte sprechen, die oben im Product Backlog hinzugefügt oder entfernt wurden.
3. Das Scrum-Team kann sich bei der Präsentation des Inkrements einfach auf die geleistete Arbeit konzentrieren.

Vergleichen Sie das Backlog jetzt mit dem letzten Mal, als wir es überprüft haben. Durch die Gegenüberstellung der beiden Backlogs wird der Fokus von geplant vs. geliefert auf die Unterschiede und die Zukunft gelegt.

Der Gesetzentwurf-Backlog-Hot-100

Bei dieser Option stellt der Product Owner das Backlog so dar, als ob er die Top-100 auf dem Billboard präsentieren würde. Hervorgehoben wird die Spitze, also die Arbeit, die bereits geliefert wurde und wahrscheinlich als nächstes geliefert wird. Die schnellsten Aufsteiger, d.h. die Punkte, die an Potenzial oder Priorität gewonnen haben. Die Punkte, die auf den letzten Platz gesunken sind. Und die mit einem Sternchen versehenen Punkte, die hervorgehoben werden müssen oder eine zusätzliche Diskussion erfordern. Diese Vorgehensweise hat auch einige Vorteile:

1. Es hebt die Arbeit "Erledigt" am Anfang der Liste hervor.
2. Es ermöglicht dem Product Owner, auf bestimmte Punkte aufmerksam zu machen.

Indem nicht gezeigt wird, was geplant war, sondern die wichtigen Änderungen im Produkt-Backlog hervorgehoben werden, wird der Schwerpunkt von geplant vs. geliefert auf die Änderungen und ihre Auswirkungen auf die Zukunft verlagert.

Die Auswirkungen bei Nichteinhaltung des Plans

"Was ist, wenn das Team nicht das geliefert hat, was der Kunde brauchte?", könnten Sie fragen. Nun, das ist eine interessante Frage...

• Trat der Bedarf auf, nachdem das Scrum-Team seinen Sprint geplant hatte?
• Hat das Scrum-Team die Arbeit prognostiziert, aber nicht geliefert?
• War die Arbeit ein wesentlicher Bestandteil des Sprint-Ziels?
• Ist der Kunde in der Lage, es zu nutzen, sobald die Arbeit "erledigt" ist?
• Kann das Scrum Team diese Arbeit in den ersten Tagen des nächsten Sprints erledigen?
• Gab es irgendwelche ungelösten Hindernisse, die dies verhindert haben könnten?

Einige dieser Fragen können aufgeworfen werden. Und es sind berechtigte Fragen. Ich schlage nicht vor, diese Fragen zu ignorieren. Ich schlage vor, sie nicht in den Mittelpunkt zu stellen.