Wie bindet man UX/UI richtig in Sprints ein, wenn Mockups benötigt werden, um eine Story einzuschätzen?

Ich möchte "voll" agil sein und das Design Teil des Sprints [...]

Ich denke, hier liegt ein Missverständnis vor, nämlich dass es in Agile nichts „im Voraus“ gibt und dass die aktuelle Iteration der einzige Ort ist, an dem Dinge passieren müssen. Wenn dieses Missverständnis besteht, versuchen die Leute, die Arbeit nur für den aktuellen Sprint zu planen und zu erledigen, was nicht immer der beste Ansatz für alle Situationen ist, wie Sie bemerkt haben.

Wenn die Designs komplex sind und Zeit brauchen, um erstellt zu werden, und es für die Entwickler wichtig ist, zu wissen, wie sie aussehen, wie sie schätzen können und welche Arbeit damit verbunden ist, dann benötigen Sie die Designs natürlich, bevor Sie Ihren aktuellen Sprint planen. Das bedeutet, dass der Designer vor den Entwicklern arbeiten sollte, um mit dem PO abzustimmen, was aus UX/UI-Sicht erforderlich ist, und die Designs im Voraus vorzubereiten.

Die einzigen Dinge, auf die Sie achten müssen, sind:

• dass der Designer nicht zum Engpass und Blocker in der Arbeit Ihres Teams wird. Sie sagen: „Manchmal sind die Designs sogar länger als unsere zweiwöchigen Sprint-Iterationen.“ Dies ist eine rote Fahne. Warum dauern sie so lange? Sind die Designs sehr komplex? Ist der Designer ein Perfektionist und neigt er dazu, Dinge zu vergolden? Ist der PO das Problem, weil sie ständig ihre Meinung darüber ändern, wie das Design aussehen sollte? Machen Sie die Verfeinerung falsch und teilen Sie die Arbeit nicht in kleinere Teile auf und müssen Sie mit einer großen Geschichte arbeiten, anstatt mit ein paar kleineren? Ist ein Designer nicht genug für die Größe des Teams? Müssen Sie mehr Designer einstellen? Was ist los? Finden Sie die Ursachen des Problems heraus, damit Sie eine Lösung finden, die tatsächlich die Probleme und nicht die Symptome behebt.
• versuche Verschwendung zu vermeiden. Wenn der Designer vor dem Team arbeitet, fehlen ihm möglicherweise einige Einblicke, die das Team bieten kann. Dies bedeutet, dass Sie riskieren, dass der Designer einige Entwürfe erstellt, die sich dann während eines Planungstreffens als in irgendeiner Weise unangemessen herausstellen und überarbeitet werden müssen. Dies verursacht Abfall. Und hier komme ich zurück zu dem, was ich zuvor erwähnt habe. Sie müssen genau darauf achten, wie viel Arbeit der Designer im Voraus leistet. Zu viel Arbeit über einen großen Zeithorizont kann viel Verschwendung verursachen. Sie müssen also „gerade genug“ arbeiten und vorausplanen, um die Entwürfe den Entwicklern rechtzeitig zur Verfügung zu haben, aber nicht so viel, dass die Designer am Ende alleine arbeiten, anstatt in das „Inspizieren, Anpassen, experimentiere und lerne"-Schleife wie der Rest des Teams.

Sie verstehen bereits, dass UX/BA-Aktivitäten vor Beginn des Sprints durchgeführt werden sollten, da Entwickler Stories für die Planung benötigen. Ihre eigentliche Frage ist, wie Sie diesen Ansatz aus der Scrum-Perspektive rechtfertigen (das ist immer die Frage bei Scrum).

Ich sehe zwei Möglichkeiten, es zu rechtfertigen:

1. UX/BA-Aufgaben sind Teil des Sprints. Ihre Aufgabe besteht jedoch nicht darin, eine funktionierende Software zu liefern, sondern es geht immer noch darum, einen Mehrwert zu liefern . Das ist alles, was wir aus Scrum-Perspektive brauchen.
2. Behandeln Sie UX/BA als Product Owner. PO muss Geschichten für die Planung vorbereiten.

Was die Verwaltung von Aufgaben betrifft: Ich persönlich würde diese Aufgaben an TODO zurückgeben und sie den Entwicklern geben. Nur um die Anzahl der zusätzlichen Geräusche im Task-Tracker zu verringern. Man kann sagen, dass die Aufgabe von UX darin besteht, diese Aufgaben für Entwickler vorzubereiten (zu beschreiben).

PS: Sie scheinen Agile und Scrum viel zu mischen. Das sind 2 sehr unterschiedliche Konzepte. Agilität ist sehr wichtig, da es im Grunde ein Synonym für Effektiv ist, während Scrum nur eine von vielen Methoden ist. Nicht die beste, wahrscheinlich nicht die schlechteste.

PPS: Versuchen Sie nicht, „vollständig agil“ zu sein. Wenn Sie das sagen, bedeutet das, dass Sie versuchen, einigen abstrakten Ideen "buchstabengetreu" zu folgen. Aber die Hauptidee von Agile ist es, flexibel zu sein und Entscheidungen zu treffen, die in Ihrer speziellen Situation sinnvoll sind. Agil ist also immer anders.

In Scrum gibt es eine Definition of Done. Ebenso wichtig ist Ihre Definition of Ready – das heißt, welche Arbeit für die Sprintplanung bereit ist.

Da jeder Station in einem Workflow ein „Fertig“-Level zugewiesen werden kann, ist es vernünftig anzunehmen, dass dies den Übergang der Arbeit in das Sprint Backlog selbst einschließt. Mit anderen Worten, bevor die Arbeit in einen Sprint eingeplant werden kann, müssen die relevanten Elemente im Product Backlog „erledigt“ sein, um ausreichend gut beschrieben und verstanden zu werden. Das Entwicklungsteam muss genug von seinem Umfang erfassen, um es in einen Sprint einplanen zu können, und eine Art Verpflichtung bezüglich seiner Implementierung formulieren, damit ein Sprint-Ziel erreicht werden kann.

— Gehen Sie durch eine Definition von Ready ( Scrum.org )

Es ist ein Irrtum, dass eine Story in einem einzigen Sprint vollständig entworfen, entwickelt und getestet werden sollte. Es bringt das Team in genau die gleiche missliche Lage, die Sie beschreiben. Das „Design“ einer Geschichte könnte viele Artefakte außerhalb des Codes enthalten. Je größer die Story, desto mehr Vorarbeit muss geleistet werden, bevor das Team den Aufwand abschätzen und die technische Lösung entwerfen kann. In der Tat ist ein Modell oder eine Art Bildmaterial unerlässlich. Sie haben auch recht, wenn Sie feststellen, dass diese Entwurfsarbeit mehr als einen Sprint dauern kann.

Erinnern Sie sich offen gesagt an das Hauptziel von Agile und Scrum: Anpassung an Veränderungen. Das Eliminieren von Big Design Up Front bedeutet nicht, kein Design im Voraus. Design genug, damit Entwickler und Tester darauf vertrauen können, dass sie die Arbeit in einem einzigen Sprint beginnen und abschließen können.

Anstatt den Workflow zum Sammeln von Anforderungen an einen Sprint anzupassen, arbeiten Sie mit den Entwicklern und Testern zusammen, um zu definieren, was für die Sprint-Planung „bereit“ ist. Lassen Sie sich vom Team sagen, welche Informationen und Designartefakte es benötigt. Dies kann informell in Form von Gesprächen oder während einer Backlog-Grooming-Sitzung erfolgen. Das bedeutet, dass UX und BA dem Team voraus sein müssen. Gehen Sie nur nicht zu weit voraus, dass UX und die BA sich nicht an Veränderungen anpassen können.

Ich sehe zwei mögliche Lösungen:

1. Betrachten Sie den UX/UI-Designer als Teil des SCRUM-Teams. Was immer er/sie tut, ist eine Geschichte, wie alle anderen Geschichten. Jetzt haben Sie das Problem auf die übliche Herausforderung reduziert, eine Aufgabe, die sich über mehr als einen Sprint oder mehr als einen erforderlichen Teilnehmer erstreckt, in Stücke zu zerlegen, die klein genug sind, um diese Probleme zu vermeiden. Er wird bei den täglichen Standups anwesend sein, kann häufig Feedback von Entwicklern erhalten, was er tun muss, um „Codierungsarbeit“ zu ermöglichen, und so weiter. Ich persönlich würde diese Lösung bevorzugen, wenn Sie sie in Ihrer Organisation zum Laufen bringen können.

2. Betrachten Sie den UX/UI-Designer als außerhalb des SCRUM-Teams. Dann ist der Output dieses Designprozesses der Input für die SCRUM User Story, was bedeutet, dass die Story zu dem Zeitpunkt, zu dem sie in einen aktiven Sprint aufgenommen wird, so sein muss, dass die Anforderungen klar sind – der Aufwand kann geschätzt werden, und es gibt einen gute Chancen, bis zum Ende des Sprints abgeschlossen zu sein.

Offensichtlich denken Sie bereits in Begriffen von "2". Geschichten werden in Verfeinerungssitzungen in den erforderlichen Zustand gebracht. Diese können leicht von den anderen Sprintartefakten entkoppelt werden; Wenn Sie beispielsweise 2- oder 3-wöchige Sprints haben, hält Sie nichts davon ab, 2 Stunden pro Woche für regelmäßig geplante Verfeinerungssitzungen aufzuwenden. In diesen Sessions ist der UX/UI-Designer wie jeder andere Stakeholder und kann den Stand seiner Arbeit präsentieren.

An dieser Stelle ist es ein guter Zeitpunkt für die Entwickler, Fragen zu Teilen des Designs zu stellen, die tatsächlich einen messbaren Einfluss auf den Aufwand haben. Zum Beispiel; Wenn ein Formular entworfen werden soll, spielt es wahrscheinlich keine allzu große Rolle, ob dem Benutzer 5 oder 6 Attribute präsentiert werden sollen. Es wird jedoch eine Rolle spielen, ob es sich eher um einen Dialog im Stil eines "Assistenten" handelt und die Frage ist, ob es 2 oder 10 Schritte geben wird. Versuchen Sie gemeinsam mit dem Product Owner, den Entwicklern und dem Designer, so viel wie nötig zu verfeinern, damit die Entwickler zumindest mit den funktionalen Teilen der Implementierung beginnen können. Dies ist auch ein guter Zeitpunkt für die Entwickler, um auf der Seite des Designers ein Verständnis dafür zu schaffen, welche seiner Entscheidungen den Aufwand beeinflussen oder nicht.

Wenn die Implementierung des Designs größer ist und mehr als einen Sprint dauert, zerlegen Sie es dennoch in kleinere Teile und implementieren Sie sie stückweise – stellen Sie sicher, dass der Designer versteht, welche Teile später schwer zu ändern sind.

Am Ende des Tages ist es wie üblich die Entscheidung des Product Owners, wann er das Team bittet, während der Sprintplanung tatsächlich mit der Arbeit daran zu beginnen; und es liegt in der Verantwortung des Entwicklerteams, zu entscheiden, ob es die Anforderungen genug versteht, um dies zu tun, und so lange Fragen zu stellen, wie es dauert.

Sie könnten „vollständig agil“ werden, indem Sie etwas namens „Design Sprint“ verwenden. Die Sache ist, dass das gesamte Team nicht gleichzeitig an Design und Entwicklung arbeiten kann. Der benutzerzentrierte Designprozess erfordert immer einen vorausschauenden Ansatz für das technische Team. Auch der UX-Prozess muss das technische Know-how des Teams, die verwendeten Technologien und Frameworks berücksichtigen.

Es gibt viele Informationen im Internet über Design-Sprints und Agile/Scrum, aber zusammenfassend sollten Sie Design-Sprints und Entwicklungs-Sprints parallel handhaben; Meiner Erfahrung nach halten sie nicht so lange. Normalerweise sind Design-Sprints länger, weil Sie Lean-Forschung und Benutzertests berücksichtigen sollten.

In dieser Situation würde ich "UI-Design" zu einem Teil des gesamten Sprint-basierten Prozesses machen.