Agile UI Design als Teil des Sprints

In letzter Zeit wurde mir häufiger die Frage gestellt, ob UI Designer zum Scrum Team gehören sollten und ob ihre Arbeit in die Scrum Sprints aufgenommen werden sollte. Da das ein wichtiges Thema ist, legen wir direkt los.

Die zwei Ziele eines agilen Sprints

Es gibt zwei Dinge, die ein Team aus jedem Sprint mitnehmen sollte:

• neue Funktionalität
• neues Wissen

Wir alle wissen, dass wir in jedem Sprint neue Funktionalität entwickeln sollten. Das ist nun mal das Ziel fast aller Projekte: den Nutzern neue Möglichkeiten zu bieten.

Teams müssen aber auch immer etwas dazulernen und nach jedem Sprint klüger sein als zuvor. Manchmal lernt ein Team etwas über eine Technologie oder darüber, wie die Nutzer eine bestimmte Funktionalität sehen. Ab und zu lernt ein Team aber vielleicht auch etwas über sich selbst und über seine Performance.

Beide Ziele sind wichtig.

Was UI Designer während des Sprints machen

Während jedes Sprints sollten auch die UI Designer die beiden oben genannten Ziele verfolgen: Funktionalität und Wissen. In einem Sprint hilft ein UI Designer dem restlichen Team, ein Design in implementierten und getesteten Code umzuwandeln, und macht sich gleichzeitig bereits Gedanken über das nächste zu entwickelnde Feature (oder die nächsten zwei). Das bedeutet, dass ein Designer sowohl im aktuellen Sprint arbeitet, als auch vorausschaut, was als nächstes kommt.

Das Ergebnis sieht dann so aus wie in der folgenden Abbildung. Darin wird deutlich, dass das Schreiben und Testen von Code zwar ein Teil des Product Backlogs ist, ein User Interface Designer aber eine bestimmte Zeit (vlt. sogar den Großteil seiner Zeit) bereits auf die nächsten Items blicken sollte. Trotzdem ist man immer noch ein Team, das in einem Sprint zusammenarbeitet.

Die erste Priorität des Designers sollte die Arbeit des aktuellen Sprints sein. Wenn ein Teammitglied Fragen zu dem Design eines Product Backlog Items hat, an dem gerade gearbeitet wird, beschäftigt sich der Designer nicht weiter mit dem nächsten Sprint, sondern beantwortet zuerst die Fragen zur Arbeit im aktuellen Sprint.

Was ist mit anderen Rollen?

Halten Sie einen Moment inne und denken Sie darüber nach, was Sie gerade alles über UI Designer gelesen haben. Und jetzt denken Sie dabei an Product Owner, Analytiker, Datenbank-Designer, Architekten und jede Rolle nach, die damit zu tun hat, was als nächstes im Projekt geschieht.

Es ändert sich nichts, außer vielleicht die zeitlichen Verhältnismäßigkeiten. Ein Designer verbringt unter Umständen die meiste Zeit damit, etwas dazuzulernen, er entwickelt aber auch ein wenig Funktionalität. Bei einer anderen Rolle ist es vielleicht genau umgekehrt. Die Zeit in einem agilen Projekt wird jedoch bei jeder Rolle immer auf das Entwickeln von Funktionalität und das Gewinnen von Erkenntnissen aufgeteilt.

Das UI Design muss nicht direkt perfekt sein

Dadurch, dass es dem Designer erlaubt ist, vorauszuschauen, kann das Team gar nicht von ihm verlangen, das Design direkt fertigzustellen. Der Designer sollte einfach so viel im Voraus erledigen, dass das Product Backlog Item vom Rest des Teams im nächsten Sprint fertiggestellt werden kann.

Am Ende des Sprints sollte das Team das Gefühl haben, dass sie das Item nicht hätten fertigstellen können, wenn sie vom Designer auch nur ein kleines bisschen weniger Informationen bekommen hätten. Das bedeutet, dass einige Product Backlog Items sehr genau betrachtet werden müssen (und das auch mehr als einen Sprint im Voraus), wohingegen andere Items vielleicht gar nicht vorab begutachtet werden müssen.

Alle Items, die ein Designer sich außerhalb des aktuellen Sprints anschauen möchte, sollten in einem Gespräch mit dem Product Owner ausgewählt werden. So vermeidet der Designer, dass er an etwas arbeitet, was der Product Owner später eventuell als unwichtig ansieht.

Führt das nicht zu einem schlechten Design?

Eine häufig auftretende Sorge ist, dass das zu einem schlechten Design führen könnte. Wäre es denn nicht besser, wenn der Designer vorab über das gesamte System nachdenken könnte? Im nächsten Blogbeitrag werde ich erklären, warum diese Vorgehensweise nicht zu schlechtem Design führt.

Certified Scrum Product Owner

=> Product Owner werden mit der Agile Academy.