Was ist eine Spike Story?

Es gibt Situationen, in denen Dein Scrum Team trotz Product Backlog Refinement nicht genau weiß, wie hoch der Aufwand für eine User Story ist oder ob diese überhaupt umsetzbar ist. In diesen Fällen kann Euch eine Spike Story dabei helfen, mehr Klarheit zu schaffen.

Spike Stories kommen (wie User Stories) aus dem Extreme Programming (kurz XP). Genauso wie diese sind sie kein fester Bestandteil des Scrum Frameworks, sondern lediglich eine weit verbreitete Praxis. (Der Scrum Guide spricht ja bekanntermaßen nur von Product Backlog Items.) Es ist also an Euch zu entscheiden, ob Ihr Spike Stories nutzen wollt oder nicht.

Die Bezeichnung Spike rührt daher, dass die Unklarheit einer User Story bzw. ihrer Umsetzung wie ein Stachel im eigenen Fleisch eines Teams sitzt. (Und dementsprechend große Schmerzen bereitet.) Eine Spike Story dient also dazu, diese Schmerzen durch mehr Klarheit zu lindern (oder bestenfalls sogar ganz so eliminieren.)

Eine Spike Story ist immer dann sinnvoll, wenn Ihr in Eurem gemeinsamen Refinement bemerkt, dass Ihr den Umfang oder der Aufwand für eine User Story nicht sinnvoll schätzen könnt. In der Regel äußert sich das dadurch, dass Ihr Euch beim Planning Poker nicht gemeinsam auf Story Points einigen könnt. (Oder sehr viele Fragezeichen-Karten ausgespielt werden.)

Die Gründe dafür können natürlich unterschiedlicher Natur sein. Meistens liegt es jedoch daran, dass entweder Deinem Team die Erfahrung fehlt oder nicht genügend Informationen über die Software vorhanden sind. (Oder auch eine ungesunde Mischung aus beidem.) Jahrealte Software mit einer undurchschaubaren Architektur, die niemand mehr genau kennt, führt also genauso zu einem Spike wie ein viele neue Entwickler im Team, die sich erst einarbeiten müssen.

Statt Euer Refinement fortzusetzen, ist es deshalb sinnvoll, das Problem (den Spike) in eine Spike Story zu verwandeln und in Eurem Sprint Planning mit ins Sprint Backlog aufzunehmen. Das heißt, ein oder mehrere Entwickler Deines Teams erproben im nächsten Sprint, ob (und wie) die angedachte Lösung umsetzbar ist (oder nicht). Die restlichen Kollegen beschäftigen sich währenddessen mit dem „eigentlichen“ Sprint.

Im besten Fall mündet eine Spike Story in einen Proof of Concept, der die Machbarkeit einer User Story bestätigt. Es kann aber auch genauso gut sein, dass die Spike Story zeigt, dass die Umsetzung nicht (oder nur sehr schwer) möglich ist. Auch das ist grundsätzlich positiv zu bewerten, weil es Dein Team davor bewahrt, sich zu verrennen.

Spike Stories haben im Vergleich zu User Stories einige Besonderheiten, die ich Dir hier kurz nennen möchte.

Das Besondere an einer Spike Story ist die zeitliche Begrenzung. Ihr einigt Euch also beispielsweise in Eurem Planning darauf, 10h für die Machbarkeit einer bestimmten User Story aufzuwenden. Ist das Zeitbudget aufgebraucht, solltet Ihr anschließend mit Eurem Product Owner besprechen, ob der eingeschlagene Weg weiterverfolgt werden soll oder nicht. Das kann auch zu einer weiteren Spike Story führen.

Eine Spike Story macht Euer Team langsamer. (Ihr müsst ja Zeit und Aufwand in eine tiefergehende Analyse stecken). Deshalb solltet Ihr keine Story Points für eine Spike Story vergeben. Sie soll Euch ja vielmehr dabei helfen, den Aufwand der dazugehörigen User Story schätzen zu können.

Die Erkenntnisse Eurer Spike Story müssen (ausreichend) dokumentiert sein, damit sie für das daran anschließende Refinement der (ursprünglichen) User Story nutzbar gemacht werden können. Schließlich hilft es Euch ja nicht, nur zu wissen, dass etwas funktioniert. Darüber hinaus möchtet Ihr nach Eurer Spike Story auch wissen, wie Ihr eine User Story umsetzen könnt.

Der während einer Spike Story entstandene Proof of Concept entspricht (in der Regel) nicht den Qualitätsansprüchen an ein Produkt. Deshalb wir er nach Abschluss des Spikes verworfen und im anschließenden Sprint so umgesetzt, dass er Eurer Definition of Done entspricht.

Natürlich ist der Einsatz einer Spike Story in bestimmten Situationen sehr sinnvoll. Allerdings zeigt er Euch auch auf, dass Euch in bestimmten Bereichen Wissen fehlt beziehungsweise die aktuelle Softwarearchitektur zu undurchschaubar ist. Beides sind Faktoren, die immer wieder dazu führen werden, Spike Stories notwendig zu machen.

Für die kontinuierliche Auslieferung eines nutzbaren und wertvollen Inkrements zum Ende Eures Sprints sind Spike Stories jedoch problematisch. Denn die Analyse einer User Story selbst stiftet noch keinen Wert.

Deshalb solltet Ihr den Gründen für die Entstehung einer Spike Story in Eurer Retrospektive auf den Grund gehen und Maßnahmen beschließen, Eure eigenen Wissenslücken zu schließen oder Eure Softwarearchitektur zu verändern.

Soviel von meiner Seite zum Thema Spike Stories. Ich hoffe, der Artikel hat Dir dabei geholfen, Sinn & Zweck dieser Art von Product Backlog Items besser zu verstehen. Falls Du noch Fragen, Ideen, Anregungen oder Kritik zu diesem Beitrag haben, hinterlasse mir einen Kommentar hier auf der Seite!