In der Conversion Optimierung macht gerade beim Testing eine agile Vorgehensweise Sinn, warum sich also nicht an etablierten Frameworks wie Scrum orientieren und davon lernen?

Der Vorteil von agilen Prozessen liegt auf der Hand:

• kurze Optimierungszyklen
• schnelle Realisierung von Optimierungen
• schnelle Reaktion auf Veränderungen

Bei Scrum läuft ein Sprint als eine Art Kurz-Projekt ab. Dieses beinhaltet alles, was auch ein normales Projekt ausmacht. Der Unterschied – der Zeitraum ist wesentlich kürzer und damit sind Änderungen und Erweiterungen schneller realisierbar.
Der Vorteil: Ein Sprint hat immer einen Release-fähigen Abschluss.

Es werden dabei keine Aufgaben geplant, sondern Stories definiert, welche innerhalb der Sprints realisiert werden. Das Ziel ist dem User ein besseres Produkt zur Verfügung stellen zu können.

Das alles kommt dem Conversion Optimierer doch sehr bekannt vor.

Anstatt Stories werden Hypothesen umgesetzt. Jeder Test kann wie ein Sprint aufgebaut werden. Die Rollen sind ähnlich.

Der Product Owner, per Definition für die strategische Produktentwicklung verantwortlich, sollte in unserem Fall für den Test selbst verantwortlich sein. Bei Agenturen könnte diese Rolle zum Beispiel der zuständige Accountmanager oder Projektleiter ausfüllen. In Unternehmen selbst beispielsweise der Verantwortliche für den Bereich, z.B. Marketingleiter.

Das Entwicklungsteam, unabhängig davon ob externer Dienstleister oder in-house, muss die für den Test erforderliche Bandbreite an Fähigkeiten beinhalten, also von der Konzeption bis zur Umsetzung alles abdecken.

Spannend wird es beim ScrumMaster. Er ist ausschließlich dafür zuständig, dass die Richtlinien eingehalten werden und damit der korrekte Ablauf gewährleistet wird. Er sorgt dafür das Scrum funktioniert.

Auch bei der Conversion Optimierung sollte im Unternehmen jemand den “Testing-Hut” aufhaben und übergeordnet dafür Sorge tragen, dass die Tests korrekt durchgeführt werden und sich demnach mit Testing auskennen. Ähnliche wie bei Scrum sollte die Rolle als “TestingMaster” niemand aus dem Entwicklungsteam sondern eine davon unabhängige Person ausfüllen, aber keinesfalls der Product Owner.

Neben der Gewährleistung des korrekten Prozessablaufs könnte der TestingMaster dafür Sorge tragen, dass die Tests korrekt durchgeführt, die Unternehmensziele nicht gefährdet werden und damit die Wertschöpfungskette im Auge behalten.

Das Zusammenspiel zwischen den einzelnen Rollen und der Ablauf eines Sprints könnte dann wie folgt aussehen:

Anstatt in einem Product Backlog die Stories zu definieren werden die durch das Entwicklungsteam erarbeiteten Hypothesen in einem entsprechenden Testplan dokumentiert. Das Backlog bei Scrum beinhaltet alle Stories entsprechend priorisiert, dies macht natürlich auch beim Testing Sinn. “Low-hanging fruits” sollten zu erst geerntet werden. Der Aufbau des Testingplans sollte demnach mit den Erfolgversprechendsten Baustellen anfangen – zum Beispiel nah an der Conversion.

Das Äquivalent zum Sprint Backlog könnte das Testkonzept sein, welches die für die einzelnen Tests erforderlichen Änderungen dokumentiert. Davon lassen sich entsprechend die einzelnen Aufgaben und Maßnahmen ableiten.

Ähnlich wie bei Scrum sollte das Entwicklungsteam am Aufbau des Testsplans bzw. -konzepts (respektive Product- bzw. Sprint Backlog) beteiligt sein. So lassen sich beispielsweise Realisierbarkeit von Hypothesen (respektive Stories) frühzeitig einschätzen und entsprechende Maßnahmen priorisieren, zeitlich abschätzen und dokumentieren. Dies würde in etwa den Sprint Planning Meetings entsprechen.

Die Sprint Review sollte am Ende der Testumsetzung erfolgen. Bei Scrum würde hier das Entwicklungsteam seine Ergebnisse vor dem Product Owner präsentieren, um sicherzustellen, dass das zu Beginn gesteckte Ziel erreicht wurde. Beim Testing ist das ähnlich. Im Rahmen der Review kann geprüft werden, ob die im Testkonzept ausgearbeiteten Hypothesen korrekt umgesetzt wurden.

Letztlich spielen hierbei auch die beiden Artefakte Definition of Done und Impediment Backlog eine große Rolle. Bei letzterem dokumentiert der ScrumMaster alle möglichen Störquellen und Hindernisse, die den Sprint gefährden könnten. Dies macht beim Testing genau so Sinn. Fragen wie “Was kann den Testlauf gefährden” sind genau so relevant wie mögliche Stolpersteine, die z.B. bei der Qualitätssicherung des Tests geprüft werden sollten.

Apropos QS. Die Definition of Done ist eine Checkliste von Aktivitäten, die zur Implementierung einer Story gehören und die Qualität der Software entsprechend beeinflussen. Im Testing kann die DoD z.B. eine Checkliste aller für den Test relevanten QS-Bausteine sein.

Bei Scrum sollte die Prüfung der User Story nie durch die Person erfolgen, welche diese umgesetzt hat. Das gilt genauso für Testing.

Ist das Qualitätsmanagement (respektive Sprint Review) erfolgreich, so steht einem Testlauf nichts mehr im Wege.

Läuft ein Test erst einmal, so sollte täglich in die Zahlen geschaut werden. Dies käme mehr oder weniger dem Daily Scrum Nahe. Der Unterschied ist, dass dies bei Scrum der täglichen Aufgabenplanung des Entwicklungsteam und dem Abgleich dient, wo man aktuell im Sprint steht.

OK, in unserem Fall ist damit eher ein täglicher Blick in die Tests gemeint, z.B. durch die Rolle analog zum Product Owner. Das ist wichtig um frühzeitig Probleme erkennen zu können und den Testverlauf aktuell im Blick zu haben.

Die Retrospektive wiederum passt sehr gut zum Testing. Hier können die Ergebnisse interpretiert, der Erfolg der Hypothesen überprüft, entsprechende Maßnahmen und ggf. neue Hypothesen abgeleitet oder letztendlich die dauerhafte Implementierung eingeleitet werden. Auch Erfahrungen aus dem Test können generell diskutiert und dokumentiert werden – beispielsweise als Lessons learned. Letzlich sollte dieser Schritt auch ggf. zur Aufbereitung der Testergebnisse und Präsentation beim Customer – also dem Auftraggeber – genutzt werden.

Fazit

In gängigen Prozessen wie Scrum lassen sich viele Gemeinsamkeiten für agile Conversion Optimierung z.B. im beschrieben Szenario “Testing” finden. Man muss eben das Rad nicht immer neu erfinden und kann sich sehr gut bestehender Frameworks bedienen.

Mehr Informationen zum Thema

> Testing-Prozess
> Scrum Framework