- Tür: Das Team schafft genau 10 Storypunkte. Gut, dann plant es für den darauffolgenden Sprint wieder 10 Storypunkte ein.
- Tür: Das Team schafft weniger als 10 Storypunkte, vielleicht nur 9. Nicht gut, und das Team plant im darauffolgenden Sprint nur 9 Storypunkte ein.
- Tür: Das Team schafft mehr als 10 Storypunkte. Aber halt, wie soll denn das funktionieren...?!
Aus diesem Grunde rate ich meinen Teams, immer mehr Stories einzuplanen, als sie beim letzten Sprint geschafft haben, die sogenannten Slackstories. Ein Verhältnis von normalen Stories zu Slackstories, mit dem wir bislang gut gefahren sind, ist 5:1, also 20 % Überplanung mit Slackstories.
Slackstories sind die Stories, die gerade eben nicht mehr in den Sprint gepasst haben. Sie sind diejenigen Stories, die im übernächsten Sprint Eingang finden würden. Daher ist es auch kein vergeudeter zeitlicher Aufwand, der in die Planung gesteckt wird: Wenn die Slackstories nicht fertig gestellt werden, sind sie die höchstpriorisiertesten Stories für den folgenden Sprint, und nur selten sind sie das nach einem Sprint nicht mehr, weil der ProductOwner sich anders entschieden hat.
Tasks, die aus Slackstories stammen, nennen wir Slacktasks. Slackstories und Slacktasks markieren wir mit einem eingekreisten S auf der Storykarte. An Slackstories arbeitet das Team erst, wenn alle anderen Stories fertig gestellt sind. Es kommt ein gutes Gefühl im Team auf, wenn man gegen Ende des Sprints Tasks einer Slackstory bearbeiten darf: Das Team weiß dann, dass es in die "Gewinnzone" gefahren ist und die Teamgeschwindigkeit steigen wird.
Das Problem mit Slack-Stories bzw. jeder Art von Überplanung ist, dass viele Teams den Slack (Freiraum), den sie hätten, um ihre Qualität zu erhöhen, technische Schulden abzubauen etc. nicht nutzen, um ihre sichtbare Geschwindigkeit zu erhöhen. Damit wird mittelfristig die Qualität wieder schlechter, es ist also eine nur scheinbare Beschleunigung. Ich rate daher meist dazu den Slack in Verbesserung der Qualität zu stecken und erst anschließend Stories vom Kunden nach zufordern, wenn immer noch Freiraum ist. Wenn der Product Owner nicht zu weit weg ist, sollte das auch machbar sein.
AntwortenLöschenIch kann nachvollziehen, dass Teams Qualität opfern, um schneller zu werden, weil sie damit glauben, besser dazustehen. Wenn ich solchen Teams begegne, versuche ich, deren Prozess auf ein qualitativ akzeptables Maß zu entschleunigen. Und wann immer ich den Eindruck bekomme, dass das Team Qualität für Features opfert, gebe ich Alarm. Soweit bin ich bei Dir, Johannes.
AntwortenLöschen(In meinen momentanen Teams mache ich mir da überhaupt keine Sorgen: In der letzten Retrospektive wurde eine sehr positiv bewertete Karte zu oberst priorisiert, auf der stand: "Ehrlichkeit bzgl. Qualität". Das Team hatte im SprintReview viele Stories nicht vorgestellt, weil deren Akzeptanztests nicht immer grün liefen, und sie wollten nichts vorstellen, was von schlechter Qualität war.)
Mit dem Nachfordern von Stories während eines Sprints habe ich sehr schlechte Erfahrungen gemacht. Der Kontextwechsel ist mir beim Nachplanen zu heftig. Die Unterbrechung des Sprints wirft die Teammitglieder teils enorm aus der Bahn. Besonders übel wird's, wenn am letzten oder vorletzten Tag vorm Sprintende die Stories ausgehen. Dann wird nur noch ein wenig geplant vorm Sprintende und nicht mehr dran gearbeitet, weil man ist ja eh schon fast mit dem Sprint durch.
Denkbar ist ja auch noch diese Variante: Wenn das Team schneller war als geplant, investiert es die gewonnene Zeit für Maßnahmen, die das Team im nächsten Sprint noch schneller machen.
AntwortenLöschenDamit ist der Nachplanaufwand weg und die von Johannes genannte Gefahr auch.