Ein Spike ist ein zeitlich begrenztes Arbeitspaket, gedacht, eine konkrete Frage zu beantworten oder eine konkrete Unsicherheit zu reduzieren, statt selbst einen Teil des Produkts zu liefern. Er ist nicht formal im Scrum Guide definiert, aber weitverbreitet genutzt, und zu verstehen, was ihn von gewöhnlicher Backlog-Arbeit unterscheidet, klärt, wann er das richtige Werkzeug ist und wann er ein Vorwand ist, eine Entscheidung zu vermeiden.
Wofür ein Spike da ist
Ein Spike existiert, um eine Frage zu beantworten, die gerade sichere Schätzung oder Planung blockiert: Kann diese externe API leisten, was gebraucht wird, welcher von zwei technischen Ansätzen ist tatsächlich machbar, wie groß ist ungefähr ein unvertrauter Problembereich. Der Output eines Spikes ist kein lieferbares Inkrement; es ist Information: eine Antwort, eine Empfehlung, oder mindestens ein deutlich besser informiertes Verständnis des Problems, als vor Beginn des Spikes bestand.
Warum er eine strenge Timebox braucht
Ohne eine feste Zeitgrenze neigt Untersuchungsarbeit dazu, sich auf die verfügbare Zeit auszudehnen, weil sich "nur noch etwas mehr Recherche" immer gerechtfertigt anfühlt, wenn das Ziel Verstehen statt eines konkreten Ergebnisses ist. Ein auf, sagen wir, zwei Tage begrenzter Spike erzwingt eine Entscheidung am Ende dieser zwei Tage: Entweder ist jetzt genug bekannt, um mit Zuversicht fortzufahren, oder nicht, in welchem Fall das selbst nützliche Information über die genuine Schwierigkeit des Problems ist, kein Grund, die Untersuchung einfach unbegrenzt zu verlängern.
Die Disziplin eines guten Spikes
Eine konkrete Frage, formuliert, bevor der Spike beginnt. "Die neue Zahlungs-API untersuchen" ist zu vage, um zu wissen, wann der Spike fertig ist. "Feststellen, ob die neue Zahlungs-API Teilrückerstattungen unterstützt, und wenn nicht, was ein Workaround kosten würde" ist konkret genug, dass der Spike eine klare Endbedingung hat.
Ein konkreter Output, nicht nur angesammeltes Verständnis. Ein guter Spike endet mit einer schriftlichen Empfehlung, einem Proof-of-Concept, oder einer klaren Antwort: etwas, worauf der Rest des Teams handeln kann, ohne die Untersuchung persönlich nachvollziehen zu müssen.
Ein echter Entscheidungspunkt am Ende. Das Team sollte den Output des Spikes nutzen, um tatsächlich etwas zu entscheiden: mit Ansatz A fortfahren, die nun besser verstandene Arbeit mit einer konkreten Schätzung bemessen, ein echtes Hindernis eskalieren. Ein Spike, dessen Erkenntnisse nie eine nachfolgende Entscheidung ändern, war es von Anfang an nicht wert, gemacht zu werden.
Wenn Spikes missbraucht werden
Der häufigste Missbrauch ist ein Spike, der still zu echter Produktentwicklung wird: Die "Untersuchung" erzeugt Code, der direkt ausgeliefert wird, ohne normale Schätzung, Review, oder Definition-of-Done-Prüfung, weil es "nur ein Spike" war. Das untergräbt genau den Schätzprozess, den der Spike eigentlich informieren sollte.
Der andere häufige Missbrauch ist, Spikes zu nutzen, um eine Entscheidung unbegrenzt zu vermeiden, die genuin nur unsicher ist statt genuin unerforscht: Spike um Spike zu einem Problem laufen zu lassen, das weitere Untersuchung nicht bedeutsam klären wird, weil das Team irgendwann die Unsicherheit akzeptieren und eine Entscheidung treffen muss, statt in der Hoffnung weiter zu untersuchen, dass irgendwann Gewissheit eintritt.