Zusammenarbeit [UX]

7 Übungsfragen mit Lösung und Erklärung.

☝️ SingleEine UX-Fachkraft ist Mitglied im Scrum Team, wird aber von einer zentralen Design-Abteilung disziplinarisch geführt und dort zu 50 Prozent verplant. Welche Wirkung ist am gravierendsten?
❌Das Team überschreitet die maximale Größe von zehn Personen
✅Die Verfügbarkeit ist nicht durch das Team steuerbar; Entwurfsarbeit wird zum Engpass, der das Sprint-Ziel von außen gefährdet
❌Die Definition of Done kann nicht mehr eingehalten werden
❌Die Person darf nicht als Developer gelten, weil sie einer anderen Abteilung angehört
Disziplinarische Zuordnung ist unkritisch; Scrum kennt keine Vorgabe zur Linienorganisation. Kritisch ist die geteilte Kapazität: Selbstverwaltung setzt voraus, dass das Team über den Einsatz seiner Mitglieder im Sprint entscheidet.
✍️ OffenEin Scrum Team liefert regelmäßig fertige Increments, doch die Nutzungszahlen neuer Funktionen bleiben durchgehend niedrig. Analysieren Sie mögliche Ursachen und beschreiben Sie, wie Sie UX-Arbeit so verankern, dass sich das ändert.
Musterantwort: Mögliche Ursachen: Das Team arbeitet lieferfähig, aber ohne Rückkopplung zum Nutzen. Anforderungen kommen als Lösungsbeschreibungen statt als Probleme, sodass niemand prüft, ob das Problem überhaupt existiert. Es gibt keine vorab formulierte Erwartung an die Wirkung, weshalb niedrige Nutzung folgenlos bleibt. Das Sprint Review inspiziert Funktionalität statt Wirkung und ist womöglich ohne echte Nutzer besetzt. Entwurfsarbeit findet vorgelagert oder außerhalb des Teams statt, wodurch Erkenntnisse nicht zurückfließen. Verankerung: Erstens jeden wesentlichen Backlog-Eintrag mit einer überprüfbaren Wirkungsannahme versehen, einschließlich Nutzergruppe, erwarteter Verhaltensänderung und Schwellenwert. Zweitens Discovery-Arbeit als sichtbare Einträge im selben Product Backlog führen, damit sie um dieselbe Kapazität konkurriert. Drittens Developers regelmäßig an Nutzerbeobachtungen beteiligen, rotierend statt vollzählig. Viertens das Sprint Review mit echten Nutzern oder zumindest mit Nutzungsdaten des letzten Sprints bestücken, statt nur Funktionen vorzuführen. Fünftens nach der Auslieferung die Wirkungsannahme tatsächlich überprüfen und das Ergebnis im Backlog wirksam werden lassen, einschließlich Rückbau nicht genutzter Funktionen. Sechstens Qualitätseigenschaften wie Barrierefreiheit und Konsistenz in die Definition of Done aufnehmen, damit sie nicht je Eintrag verhandelt werden. Entscheidend ist die Haltung: Lieferfähigkeit ist eine Voraussetzung für Wert, aber kein Nachweis von Wert.
Bewertet werden: Unterscheidung Output/Outcome + mindestens drei plausible Ursachen + Wirkungsannahmen mit Schwellenwert + Discovery im selben Backlog + Beteiligung der Developers an Beobachtung + Überprüfung nach Auslieferung samt Rückbauoption.
☝️ SingleEin Entwurf wird im Sprint umgesetzt und weicht an mehreren Stellen von der Vorlage ab, weil technische Beschränkungen auftraten. Wie ist damit umzugehen?
✅Die Abweichungen gemeinsam bewerten: Wo die Absicht erhalten bleibt, ist die Anpassung richtig; wo sie verloren geht, ist eine gemeinsame Lösung zu suchen
❌Der Product Owner entscheidet über jede einzelne Abweichung
❌Die Vorlage ist verbindlich und muss exakt umgesetzt werden
❌Die technische Lösung hat Vorrang, der Entwurf wird nachgezogen
Ein Entwurf ist eine Hypothese über eine gute Lösung, kein Vertrag. Maßgeblich ist die dahinterliegende Absicht. Beide Extreme scheitern: Exakte Umsetzung ignoriert die Realität, freie Anpassung verliert die Absicht.
☝️ SingleEine UX-Fachkraft und ein Developer sind unterschiedlicher Meinung über eine Interaktionslösung. Wie sollte die Frage entschieden werden?
❌Der Developer entscheidet, da er die Umsetzung verantwortet
❌Die UX-Fachkraft entscheidet, da Interaktion ihr Fachgebiet ist
✅Wenn möglich durch eine Prüfung mit Nutzern oder Daten; wo das nicht geht, entscheidet das Team gemeinsam anhand der Wirkungsabsicht
❌Der Product Owner entscheidet, da er den Wert verantwortet
Meinungsstreit über Gestaltung ist ein Anlass, die Annahme zu prüfen, statt Zuständigkeiten auszuspielen. Oft genügt ein kleiner Test mit wenigen Personen. Erst wenn eine Prüfung unverhältnismäßig wäre, entscheidet das Team.
☝️ SingleWas bedeutet der Grundsatz "geteiltes Verständnis vor ausführlicher Dokumentation" für die Entwurfsarbeit?
❌Entwürfe müssen mündlich übergeben werden
❌Entwurfsdokumentation ist in Scrum nicht vorgesehen
❌Dokumentation entsteht erst nach der Auslieferung
✅Gemeinsam erarbeitete Entwürfe brauchen weniger Übergabedokumente; Dokumentation dient dem Erinnern, nicht dem Erklären an Abwesende
Umfangreiche Spezifikationen entstehen dort, wo Menschen nicht zusammenarbeiten. Wer den Entwurf gemeinsam entwickelt hat, braucht keine Erklärung. Das heißt nicht, dass nichts festgehalten wird; es heißt, dass Festgehaltenes das Gespräch nicht ersetzt.
✍️ OffenIhr Scrum Team soll UX-Arbeit integrieren. Bisher lieferte eine zentrale Abteilung fertige Entwürfe. Beschreiben Sie den Übergang über die ersten drei Monate.
Musterantwort: Im ersten Schritt würde ich nicht die Struktur ändern, sondern die Zusammenarbeit. Die bisherige Entwurfsperson nimmt an Sprint Planning, Refinement und Review teil und arbeitet während des Sprints mit den Developers, statt vorab zu liefern. Das erzeugt sofort Reibung an genau den Stellen, die später zu klären sind, und macht sie sichtbar, ohne dass jemand eine Reorganisation beschließen müsste. Parallel würde ich die Backlog-Einträge umstellen. Solange Einträge fertige Lösungen beschreiben, gibt es im Sprint nichts zu gestalten. Einträge, die ein Ergebnis für eine benannte Nutzergruppe beschreiben, sind die Voraussetzung dafür, dass Entwurfsarbeit überhaupt in den Sprint passt. Im zweiten Monat würde ich Nutzerzugang aufbauen, weil das der häufigste Engpass ist und die längste Vorlaufzeit hat. Fünf wiederkehrende Gesprächspartner, an denen alle zwei Wochen etwas geprüft werden kann, verändern mehr als jede Methodenschulung. Dabei nehmen rotierend auch Developers teil. Ebenfalls im zweiten Monat würde ich die Definition of Done erweitern, zunächst um wenige, prüfbare Punkte: Barrierefreiheit auf definiertem Niveau, leere Zustände, Fehlerzustände, Konsistenz mit dem Design-System. Das verankert Entwurfsqualität, statt sie je Eintrag zu verhandeln. Im dritten Monat würde ich den Vorlauf abbauen. Solange noch ein Sprint Entwürfe auf Vorrat existiert, bleibt die Übergabe bestehen. Der Abbau geht schrittweise: erst halbieren, Wirkung beobachten, dann auflösen. Mit der zentralen Abteilung würde ich früh über die neue Aufgabenteilung sprechen. Sinnvoll bleibt sie für das Design-System, für übergreifende Forschung und für fachliche Weiterentwicklung der Entwurfsarbeit. Als Lieferant fertiger Entwürfe entfällt sie. Diese Perspektive gehört ausgesprochen, sonst entsteht Widerstand aus Sorge um die eigene Rolle. Woran ich Erfolg messen würde: Anteil der Sprints, in denen Entwurfsänderungen aufgrund von Erkenntnissen erfolgten; Zeit zwischen Entwurf und erster Nutzerrückmeldung; Anteil der Einträge, die als Ergebnis statt als Lösung formuliert sind.
Bewertet werden: Zusammenarbeit vor Struktur + Umstellung der Backlog-Einträge auf Ergebnisse + Nutzerzugang als Engpass mit Vorlaufzeit + Erweiterung der Definition of Done um prüfbare Punkte + schrittweiser Abbau des Vorlaufs + Perspektive für die zentrale Abteilung + überprüfbare Erfolgsgrößen.
✌️ MultiWoran erkennt man, dass Entwurfs- und Umsetzungsarbeit tatsächlich zusammenwirken? (Mehrere richtig)
✅Gestaltende Personen kennen die technischen Beschränkungen des Systems
❌Änderungswünsche laufen über ein Ticketsystem zwischen beiden Seiten
✅Developers stellen Rückfragen zur Absicht, nicht nur zur Darstellung
❌Entwürfe werden vor Sprintbeginn vollständig abgenommen
✅Entwürfe ändern sich während des Sprints aufgrund technischer oder fachlicher Erkenntnisse
Die letzten beiden Punkte beschreiben Übergabemerkmale: eine Abnahmestufe und einen förmlichen Kommunikationsweg. Beide entstehen typischerweise dort, wo Menschen nicht gemeinsam arbeiten.
← Alle ThemenIm Quiz üben