Was tun Sie, wenn die Lösung für eine User Story unklar ist? Wenn Sie eine neue Technologie einführen wollen, aber nicht wissen, ob dies die richtige Lösung ist? Wenn Sie kein Verständnis für Risiken haben und daher nicht wissen, wie Sie eine Story bewerten sollen? Für solche Fälle verwenden wir in Scrum einen Spike. In diesem Beitrag werden Sie mehr darüber erfahren.
Was ist ein Spike?
Hin und wieder stoßen Sie und Ihr Scrum Team auf ein Product Backlog Item, das Sie nicht weiter verfeinern können. Wahrscheinlich liegt das an fehlendem Fachwissen oder an mangelnden Kenntnissen über die zu verwendende Technologie.
Ein Spike ist eine spezielle Art von User Story, die dazu dient, das notwendige Wissen zu erlangen, um Risiken, Anforderungen oder erforderliche Story Points besser zu visualisieren. Spikes helfen Ihnen, sich ein besseres Bild von einer Story zu machen und die Richtung (neu) zu definieren. Außerdem weisen Sie jedem Spike eine Timebox zu, damit Sie nicht endlos recherchieren müssen. Außerdem nehmen Sie Spikes in Ihr Sprint Backlog auf, genau wie normale User Stories.
Der Begriff Spike stammt aus einer Analogie zum Bergsteigen. So erklärt sich auch der Name: Beim Klettern macht man vielleicht eine Pause, um einen Nagel in die Bergwand zu schlagen. Den Nagel in die Wand zu schlagen ist nicht gleichbedeutend mit dem Klettern selbst – es bringt uns dem Gipfel nicht näher – aber es sorgt dafür, dass wir unser Ziel sicherer erreichen können.
Arten von Spikes in Scrum
Es wird zwischen zwei verschiedenen Arten von Spikes unterschieden: technische und funktionale Spikes.
Technische Spikes
Technische Spikes werden verwendet, um einen Überblick über Umweltfaktoren und Risiken bei der Implementierung einer bestimmten technischen Lösung zu erhalten. Erwägen Sie die Verknüpfung von einem Softwarepaket mit einem anderen. Falls dies noch nie gemacht wurde, kann es viele Risiken mit sich bringen. Kann das Softwarepaket verknüpft werden? Wie können wir testen, ob alles richtig funktioniert? Wissen wir, welche Schritte wir durchlaufen müssen? Technische Spikes können auch eingesetzt werden, wenn im Team nicht genügend Wissen vorhanden ist, um Klarheit über die User Story, die Lösung oder den Weg dorthin zu schaffen.
Funktionale Spikes
Funktionale Spikes werden verwendet, um – der Name sagt eigentlich schon alles – die Funktion, den Betrieb bestimmter Gegenstände im Voraus zu bestimmen. Wir können zum Beispiel Zweifel daran haben, wie der Endnutzer reagieren wird, wenn wir unser Produkt oder unsere Dienstleistung anbieten. Das kann man zum Beispiel mit Hilfe von Prototypen oder Mock-Ups untersuchen.
Einen Spike einschlagen ist keine Kletterarbeit
Ein Spike ist also eher ein Stück Vorforschung als eine tatsächliche Arbeit, die sich daher wirklich auf das Stück Vorforschung beschränkt. Denken Sie an das Beispiel mit dem Bergsteigen: In dem Moment, in dem Sie den Nagel in die Wand schlagen, klettern Sie nicht auch hinauf.
Das sind zwei getrennte Aktionen. Das Klettern selbst ist eine separate User Story, die je nach dem Ergebnis des Spike ausgeführt werden kann oder nicht, oder geändert werden muss.
Der Forschungsteil gehört also zum Spike. Vielleicht sollte man über die linke oder die rechte Seite hinaufklettern, vielleicht ist das Klettern gar nicht möglich und man sucht sich einen anderen Felsen.
Verwendung von Spikes
Da Spikes keinen direkten Kundennutzen bieten, sollten sie nicht häufig eingesetzt werden. Sie sollten auch nicht anfangen, Spikes (teilweise) als Ersatz für Refinementaktivitäten zu verwenden. Spikes sollten nur dann eingesetzt werden, wenn das Refinement nicht ausreicht, um den Wert und die Lösung der User Story zu klären, oder wenn nicht genügend Wissen vorhanden ist, um eine Story zu klären.
Denken Sie auch daran, dass ein Spike normalerweise einen Sprint vor dem Sprint der entsprechenden Story geplant werden sollte. Das liegt daran, dass es riskant ist, einen Spike zusammen mit der zugehörigen Story zu planen: Wenn Sie feststellen, dass die Story geändert werden muss oder nicht mehr durchgeführt werden kann, führt dies zu Problemen in Ihrem Sprint Backlog.
Spikes und agile Unsicherheiten
Ungewissheit ist Teil des agilen Denkens und der daraus hervorgegangenen Frameworks. Ein Beispiel dafür ist die wiederkehrende Sprint Review im Scrum Framework, mit dem immer wieder überprüft wird, ob wir auf dem richtigen Weg sind. Auch bei der Schätzung von Stories werden Unwägbarkeiten berücksichtigt, ebenso wie bei der Verwendung von Story Points. Denken Sie daran, dass Sie im Planning Poker nicht genau 4 Punkte schätzen können, sondern zwischen 3 und 5 wählen müssen. Und dann kann man sich nicht für 6 oder 7 entscheiden, sondern 8 Punkte sind die nächste Möglichkeit. Die Ungewissheit ist Teil des Spiels.
Wenn die Unsicherheit bereits in unsere Arbeitsweise eingebaut ist, brauchen wir keine Spikes, oder? Das stimmt zum Teil: Die meiste Zeit werden Sie keine Spikes brauchen. Sie werden bereits in der Lage sein, während der Verfeinerung einen klaren Rahmen für die Geschichte und die Lösung zu schaffen. Spikes sind also wirklich nur dann nötig, wenn es keinen anderen Weg gibt.
