Ratgeber

Ein gutes Doppel: Scrum und User-Experience-Design erfolgreich anwenden

Seite 2 / 2

Erfolgsfaktor 2: UX-Design schon in Sprint 0 berücksichtigen – für relevante Personas und gute User Stories

Im Scrum-Prozess wird die Zeit vor dem ersten Sprint für vorbereitende Maßnahmen genutzt, etwa die Aufstellung der technischen Architektur. Dieser Zeitraum wird auch als Sprint 0 bezeichnet. In diese Phase lassen sich die ersten konzeptionellen und kreativen Prozessschritte des UX-Designs gut integrieren. Ziel von Sprint 0 ist in diesem Fall, gemeinsam ein grundlegendes Verständnis für den User und eine einheitliche Produktvision zu erarbeiten.

Hierfür empfiehlt sich ein Workshop, in dem alle Projektbeteiligten – Entwickler, User-Experience-Designer, Product Owner und idealerweise auch die Stakeholder – ein Big Picture der UX-Idee entwickeln. Ebenso sollten bereits in Sprint 0 die ersten Schritte des UX-Designs umgesetzt werden: User Research, Persona-Erstellung und das Erarbeiten von Anforderungen in Form von User Stories. Auf dieser Basis können die Beteiligten gemeinsam ein für alle verständliches Product Backlog erarbeiten. Bereits im Sprint 0 sollten Daily-Scrum-Meetings stattfinden, in denen sich die Teammitglieder gegenseitig über den Fortschritt und aktuellen Stand der Vorbereitungsphase informieren.

Die User Stories, die im Sprint 0 zusammen erarbeitet werden, sortiert der Product Owner am Ende des Sprints nach ihrer Priorität. Am höchsten werden die User Stories priorisiert, die das sogenannte Minimal Viable Product (MVP) abbilden – also das Produkt oder Feature, welches mit dem geringsten Aufwand den größtmöglichen Nutzen für den User bringt. Diese User Stories sollten dann in den ersten Sprints umgesetzt werden.

(Grafik: Shutterstock)

(Grafik: Shutterstock)

Um abschätzen zu können, wie viele Sprints benötigt werden, um das MVP umzusetzen, sollten die Entwickler in Sprint 0 eine Aufwandsschätzung der priorisierten User Stories vornehmen. Aufgabe der User-Experience-Designer in dieser Phase ist es, den Wert und Nutzen einer User Story zu beschreiben und die Entwickler an den Aufwand für die Umsetzung des Designs zu erinnern.

Für die Entwickler kann es schwierig sein, eine Aufwandsschätzung abzugeben, wenn noch kein definiertes User-Experience-Design vorhanden ist. Um ein gemeinsames Verständnis – und damit eine genauere Schätzung – der User Stories zu erreichen, empfiehlt es sich, während Sprint 0 einfache (Papier-)Prototypen zu erstellen. Die Ideen aller Projektbeteiligten lassen sich auf diese Weise schnell visualisieren und so besser in der Gruppe diskutieren. Die tragfähigsten Ideen können dann weiterentwickelt und idealerweise anhand von Prototypen noch in Sprint 0 auf ihre Benutzerfreundlichkeit getestet werden, zum Beispiel von Kollegen. Das Feedback der Tester lässt sich dann in einer schnellen Iteration berücksichtigen.

Der parallelen Entwicklung geschuldet, wird es im Laufe des Projekts nur noch den User-Experience-Designern möglich sein, den kompletten Prozess immer wieder durchzuführen, also kontinuierliche User Research, Anpassung – und falls erforderlich Neuerstellung – von Personas, Erstellung und Testung von Prototypen etc. vorzunehmen. Die User-Experience-Designer sollten im Laufe des Prozesses darauf achten, ihre gewonnenen Erkenntnisse und Resultate regelmäßig mit dem restlichen Team zu teilen.

Erfolgsfaktor 3: UX-Designer an allen Scrum-Meetings beteiligen – für das „Big Picture“

Voraussetzung für eine ganzheitliche Integration der User-Experience-Designer in den Scrum-Prozess ist deren Teilnahme an allen Scrum-typischen Meetings. Dazu zählen Daily Scrum, Plannings, Product Backlog Refinement, Retrospektiven und Reviews.

Im Rahmen dieses „institutionalisierten“ Austauschs zwischen Entwicklern und User-Experience-Designern – idealerweise zusätzlich unterstützt durch räumliche Nähe – können beide Gruppen schnell herausfinden, ob sich das erstellte UX-Design mit angemessenem Aufwand umsetzen lässt. Weiterhin haben die Entwickler so auch die Möglichkeit, ihre Ideen und Ansichten in den UX-Design-Prozess einfließen zu lassen.

Ebenfalls empfiehlt sich eine enge Zusammenarbeit zwischen UX-Designern und Product Ownern, speziell bei der Ausgestaltung von User Stories. Sie können ihre Erfahrung im Umgang mit den Nutzern und deren Bedürfnisse bei der Erstellung von User Stories einfließen lassen und User-Experience-Designs zu den geplanten User Stories anfertigen. Dabei sollte darauf geachtet werden, sehr detailliertes User-Experience-Design erst dann zu erstellen, wenn es benötigt wird – und nicht schon weit im Voraus. Das Gleiche gilt auch für die finale Ausformulierung der User Stories, da es sehr wahrscheinlich ist, dass sich initiale User Stories aufgrund neuer Erkenntnisse im Laufe des Projekts ändern. Somit ist es ratsam, die User Stories auch hinsichtlich ihrer User Experience erst ein bis zwei Sprints vor der geplanten Umsetzung zu finalisieren, um den Arbeitsaufwand zu minimieren.

(Grafik: Medium.com)

Als fester Bestandteil eines Scrum-Teams stehen die User-Experience-Designer jederzeit für Rückfragen zur Verfügung. Das trägt dazu bei, Mehrfacharbeit zu verhindern, etwa wenn ein Detail zum Verhalten des User Interfaces vom Entwickler anders verstanden und ohne Rückfrage implementiert wurde. Indem sie die Akzeptanzkriterien einer User Story prüfen, unterstützen die UX-Designer auch den Product Owner, der die User Stories maßgeblich mitprägt.

User-Tests sind ein weiteres Aufgabenfeld, dessen sich UX-Designer während der Entwicklung annehmen können. Hierfür empfiehlt es sich, mit ausgewählten Anwendern in regelmäßigen Abständen – etwa alle zwei Sprints – Usability-Tests durchzuführen, idealerweise zunächst mit Prototypen. So hat die Zielgruppe die Möglichkeit, neu implementierte Produktinkremente zu evaluieren. Eine frühe Rücksprache mit den Anwendern hat den Vorteil, dass etwaige Änderungswünsche der User umgehend berücksichtigt werden können. Insbesondere, wenn die Anpassungen bereits an Prototypen erfolgen und nicht erst an der bereits entwickelten Software, bedeutet das enorme Zeit- und Kostenersparnisse. Anpassungen lassen sich direkt in einer darauffolgenden Iteration vornehmen, oder die Änderungswünsche werden in neuen User Stories verankert. Um den transparenten Austausch mit dem Scrum-Team aufrechtzuerhalten, sollten die UX-Designer die Ergebnisse der User-Tests im Daily Scrum präsentieren.

Fazit

User-Experience-Designer können in einem Scrum-Team umfassende Aufgaben übernehmen und wesentlich zum Erfolg des Produkts beitragen. Voraussetzung dafür ist, dass die UX-Designer als Doppelpartner der Entwickler im Scrum-Prozess mitspielen. Zum einen ist es ihre Aufgabe, nach vorne zu schauen und mittels User Research, User-Tests und Prototyp-Erstellung eine auf den Anwender ausgerichtete Entwicklung des Produkts voranzutreiben. Zum anderen sollten sie immer für Nachfragen der Entwickler bezüglich aktuell bearbeiteter User Stories verfügbar sein, die bereits implementierten User Stories validieren und gegebenenfalls an der Zielgruppe testen.

Dabei sollten sich alle Beteiligten bewusst sein, dass es in der agilen Softwareentwicklung im Grunde keine endgültige Lösung gibt. Mit sich verändernden Bedürfnissen der User muss sich schließlich auch das Produkt verändern – indem es stetig angepasst und weiterentwickelt wird. Daher sind mit der Freigabe eines Softwareprodukts die Entwicklung und das User-Experience-Design nicht abgeschlossen. Im Prinzip beginnt in diesem Moment schon ein neues Match.

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

5 Kommentare
Andre Böker
Andre Böker

räumliche Nähe ist überhaupt nicht relevant. Wir nutzen fast täglich Skype mit Bildschirmübertragung in der Entwicklung von Verwaltungssystemen.

Antworten
derDoubleD

Hallo Andre. Super, dass das bei euch so klappt – kann und muss deswegen nicht allgemeingültig sein. Was sind aus deiner Sicht die Erfolgsfaktoren, dass dieses Remote-Arbeiten funktioniert?

Antworten
Andre Böker
Andre Böker

Hallo DoubleD,

am besten sind gleiche Arbeitszeiten oder eine Abstimmung, wann man über Vorlagen und Lösungsbeispiele, konkrete Aufgaben, erreichte Ergebnisse, gewonnene Erfahrung, erkannte Fehler und abgeleitete Verbesserungen spricht.
Zeigt man den Entwicklern nicht, dass man die Lösung und Probleme bereits kennt, liefern sie nur das nötigste ab und das ist in der Regel nur ausreichend.

Mehr möchte ich an dieser Stelle nicht sagen.

derDoubleD

Hier die Slides eines passenden Erfahrungsberichts: Agile UX – oder We have not failed. We’ve just found 10.000 ways that didn’t … #agile #experience http://www.slideshare.net/derDoubleD/agile-ux-oder-we-have-not-failed-weve-just-found-10000-ways-that-didnt-work-nach-edison via @SlideShare

Antworten
Alex

Meine Erfahrung als Agile Coach zeigt, dass die Integration von UX und Design in das Scrum-Team eine wesentliche Voraussetzung für eine erfolgreiche Produktentwicklung ist. Gleiches gilt auch für Tester, Ops bzw. alle Expertisen, die benötigt werden, damit ein Team ein Produkt möglichst unabhängig entwickeln kann. Das fällt für mich unter Cross-functional Teams.
Bisher hält sich aber manchmal noch die Idee, dass das Interface und das Design möglichst vollständig vorab entwickelt werden und im Nachgang von den Entwicklern lediglich umgesetzt werden. Das entspräche aber eher einem Mini-Wasserfall im agilen Gewand.
So früh wie möglich sollten Prinzipien und Guidelines erstellt werden, damit sich das Produkt am Ende wie „aus einem Guss“ anfühlt. User-Stories bis ins kleinste Detail zu spezifizieren – womöglich schon im Sprint 0 und pixelperfekt – ist unmöglich und widerspricht dem Ziel agiler Methoden. Das gleicht eher klassischen Vorgehensweisen.
Ist es nicht sinnvoller, dass das gesamte Team gemeinsamen Guidelines folgt, Stories gemeinsam definiert und auch gemeinsam umsetzt?
Für neue (besonders knifflige) Features können die Teammitglieder mit ihren unterschiedlichen Expertisen regelmäßig und parallel zum aktuellen Sprint (Timeboxing), gemeinsame Product-Discoveries durchführen, wo auf UX und Designfragen eingegangen werden kann und auch die technische Machbarkeit überprüft wird, wo auch verschiedene Varianten ausprobiert und Prototypen evaluiert werden.
Die Ergebnisse und Erfahrungen daraus fließen dann in die entsprechenden Stories ein. Der Vorteil ist, dass das Team frühzeitig eine gemeinsame Richtung erarbeitet und alle das gleiche Zielbild im Kopf haben. Das Team beschäftigt sich so noch viel mehr mit dem eigenen Produkt!
Zudem wird durch diesen integrativen Ansatz die Distanz zwischen einzelnen Expertisen abgebaut und gegenseitiges Verständnis aufgebaut – am Ende benötigen wir ja EIN funktionierendes Team. Auch jeder Entwickler kann mit der aufgesetzten Kundenbrille wertvollen Input zur Produktentwicklung geben und nicht nur Code hacken ;)

PS: Soweit ich mich entsinne, ist der PO per Definition für die Bestimmung und Kommunikation von Wert und Nutzen einer Story verantwortlich, niemand sonst. Die Informationen dafür können aber natürlich von jedem aus dem Team oder von außerhalb kommen.
PPS: Räumliche Nähe ist immer vorteilhafter und kann gleichwertig nur schwer durch Tools ersetzt werden. Es ist aber nicht unmöglich.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung