Scrum: Ist es in Ordnung, dass das Design / UX der User Story im selben Sprint wie die Implementierung erfolgt?

Ich bin derzeit in einem Sprint (zwei Wochen), in dem der Designer die Aufgabe hat, die Anforderungen und die Benutzeroberfläche einer bestimmten User Story zu definieren.

Im gleichen Sprint soll ich dieses Design umsetzen. Während der Sprintplanung musste ich eine wilde Vermutung anstellen, wie lange diese undefinierte User Story dauern würde.

Heute habe ich endlich das Design erhalten. Leider ist das Design unvollständig / vage und entspricht eher den Anforderungen eines Kunden als einem Design. Daraus kann ich jedoch immer noch ersehen, dass ich nicht annähernd genug geschätzt habe.

Um die Sache noch schlimmer zu machen, ist dies nicht das erste Mal. Im letzten Sprint passierte genau das Gleiche. Ich habe es in unserer Retrospektive markiert und der Scrum Master hatte keine Antwort darauf, wie man das löst, anstatt zu sagen "das ist nur Entwicklung für Sie". Ironischerweise ärgert er sich, wenn der Abbrand nicht am Ziel ist ...

Jetzt muss ich den Designer fragen / mit ihm zusammenarbeiten, um seine Arbeit zu erledigen. Dies wird mich aufhalten, da ich alle meine anderen Aufgaben erledigt habe.

Meine Frage ist also

Wie gehen Sie mit Abhängigkeiten in der Sprintplanung um?

Im Idealfall werden nicht entwicklungsbezogene Abhängigkeiten vor der Sprintplanung behandelt, sodass Sie eine gute Definition des Backlog-Elements haben, anhand derer Sie den Aufwand abschätzen können.

Aber wenn das im letzten Sprint "nur Entwicklung für Sie" war, dann war das wahrscheinlich nur Entwicklung für Sie in diesem Sprint, also hätten Sie Ihre Schätzung dort und dann bei anstehenden Aufgaben, die sich in einem ähnlichen Zustand befinden, wirklich erhöhen müssen. Dies ist nicht rachsüchtig, und es wäre ein Fehler, es als solches erscheinen zu lassen.

Was es tut, ist die Unsicherheit der Schätzung ohne ein relativ solides Design, gegen das geschätzt werden kann. Dies wird Ihre Manager möglicherweise dazu ermutigen, sicherzustellen, dass ein Produkt-Backlog-Element ordnungsgemäß definiert ist. aber im schlimmsten Fall wird es Ihren Rücken bedecken. Niemand beschwert sich, wenn ein Job unter dem Budget liegt.

Das haben Sie jedoch nicht getan, und jetzt lautet Ihre Frage ...

Wie soll ich mich jetzt dem Sprint nähern?

Der gesamte Zweck von Scrum als Projektmanagement-Tool besteht darin, Probleme frühzeitig zu erkennen, was Sie getan haben. Melden Sie es Ihrem Management an und lassen Sie es entscheiden, was mit dem Sprint geschehen soll. Wenn sie versuchen, Ihnen die Schuld zu geben, seien Sie demütig und fragen Sie, wie sie vorschlagen, dass Sie in Zukunft ähnliche Situationen angehen, um dasselbe Problem zu vermeiden, auch wenn Sie nicht wirklich glauben, dass es fair ist.

Letztendlich handelt es sich hierbei um Projektmanagementprobleme. Wenn Sie versuchen, diese Probleme in Ihrer eigenen Blase zu lösen, können Sie scheitern. Und wenn Sie dies tun, werden Sie wütend sein, weil es auf Sie fällt, nicht auf die Manager, die das Problem nicht gelöst haben, als Sie es ihnen gemeldet haben.

Zunächst einmal gibt es einen großen Unterschied zwischen Abhängigkeiten zwischen Geschichten / Aufgaben und Unsicherheit im Umfang / Aufwand einer Geschichte / Aufgabe.

Abhängigkeiten werden behandelt, indem der abhängigen Aufgabe / Story eine niedrigere Priorität als der Aufgabe / Story zugewiesen wird, von der sie abhängt, und möglicherweise eine Anmerkung, die nicht gestartet werden kann, bevor die andere Aufgabe / Story erledigt ist.

Die Unsicherheit sollte in der Planungsbesprechung angegangen werden, indem die Arbeit geklärt wird, die an der Geschichte durchgeführt werden muss. Wenn es nicht möglich ist, genug von der Unsicherheit zu beseitigen, entspricht die Geschichte höchstwahrscheinlich nicht Ihrer "Definition of Ready" und sollte nicht in den Sprint aufgenommen werden.
Wenn die Geschichte aus irgendeinem Grund wirklich in den Sprint gehen muss, besteht Ihre einzige verbleibende Option darin, der Schätzung einen Risikopuffer hinzuzufügen.

Wenn Sie für den aktuellen Sprint nicht an einer Story arbeiten können, melden Sie dies einfach in der nächsten täglichen Besprechung und führen Sie alle möglichen Arbeiten aus, um das allgemeine Sprintziel des Teams zu erreichen. Sie können die Geschichte auch als blockiert und durch was kommentieren.
Nach dem Start eines Sprints ist es grundsätzlich unmöglich, dem Sprint neue Aufgaben hinzuzufügen.
Wenn sich herausstellt, dass eine Aufgabe mehr Arbeit als geschätzt ist, ändern Sie die Schätzung nicht, berichten jedoch genau über den Fortschritt und den verbleibenden Aufwand für die Aufgabe.

Am Ende ist es in Scrum das Team, das verspricht, etwas zu liefern. Wenn dieses Versprechen nicht gemacht werden kann, ist es ein Misserfolg des gesamten Teams, niemals eines Einzelnen innerhalb des Teams.

Während der Sprintplanung musste ich eine wilde Vermutung anstellen, wie lange diese undefinierte User Story dauern würde.

Das ist der Fehler, den du gemacht hast. Niemand kann das Team zwingen, eine Aufgabe im Sprint anzunehmen, und es ist Ihre Aufgabe, anzugeben, dass die Aufgabe im Sprint nicht geschätzt und angenommen werden kann, es sei denn, es gibt mindestens ein Drahtmodell (zum Beispiel). Es scheint, dass Ihr Scrum Master tatsächlich ein Projektmanager ist, was die Sache nur noch schlimmer macht.

Wie kann man sich einer solchen Aufgabe nähern, wenn es notwendig ist, sie im Sprint zu erledigen (aus gültigen geschäftlichen Gründen)? Nun, zuerst müssen Sie eine Frist für das Design festlegen, nach der Sie es nicht mehr implementieren können. Zum Beispiel: Die Geschichte wird akzeptiert, aber das Design sollte innerhalb der ersten Woche geliefert und innerhalb der zweiten implementiert werden. Als nächstes müssen Sie sehr eng mit dem Designer zusammenarbeiten, um sicherzustellen, dass es im Sprint implementiert werden kann. Scrum übernimmt ein funktionsübergreifendes Team und es liegt an Ihnen, Ihre Arbeit mit dem Designer zu organisieren. Wenn Sie jedoch die Aufgabe im Sprint annehmen - über die das Team entscheiden muss -, muss das Team die Arbeit so verwalten, dass sie im Sprint abgeschlossen ist, und die damit verbundenen Risiken verwalten. Sie sollten nicht darauf warten, dass ein anderer seinen Job beendet, um Ihren Job zu erledigen. Es ist möglich, dass Sie im Begriff sind, eine größere Funktionsstörung in Ihrem Unternehmen aufzudecken.

Werden die Aufgaben zum Thema Design als Geschichten ausgedrückt und wie lauten die Definitionen Ihres Teams?

• Eine Geschichte ist fertig
• Eine Geschichte ist fertig

Jede Geschichte sollte ihre eigenen Anforderungen und Akzeptanzbedingungen haben, aber ich denke, es ist eine gute Praxis, eine Reihe von Regeln zu haben, die für alle Geschichten gelten. Zum Beispiel ist eine Geschichte fertig, wenn (und nur wenn!): Die durchgehenden Architekturstudien sind abgeschlossen, das Design ist verfügbar, die Geschichte wurde vom Team geschätzt. Minimale Akzeptanzbedingungen könnten sein: Der automatisierte Test ist durchgeführt, OK und wurde in den Testanzug integriert, die Codeüberprüfung wird durchgeführt.

Wenn eine Geschichte noch nicht fertig ist, binden Sie sie nicht in Ihren Sprint ein. Wenn die Annahmebedingungen nicht erfüllt sind, ist sie noch nicht abgeschlossen.

In Ihrem Fall könnte das Team entscheiden, dass eine Entwicklungsgeschichte ein vollständiges Design haben muss, um bereit zu sein (mindestens ein Drahtmodell, passen Sie dies an Ihre eigene Realität an). In diesem Fall können Sie Design und Entwicklung nicht im selben Sprint ausführen. Das Team könnte auch entscheiden, dass eine UX / Design-Story mindestens ein Drahtgitter-Design hervorbringen soll. Wenn dies nicht der Fall ist, wird die Geschichte nicht akzeptiert und daher können die davon abhängigen Geschichten nicht gestartet werden.

Sie sollten Ihre Manager leicht davon überzeugen können, dass es gut ist, strenge Regeln für die Bereitschaft zu haben: Die Neubewertung der Komplexität während des Sprints ist eine schlechte Praxis. Dies bedeutet, dass die Geschwindigkeit des Teams ungewiss ist und dass sie als Manager eine schlechte Vision von der Arbeit des Teams und der Zukunft haben.

Ein Sprint beginnt normalerweise, wenn die Geschichte klar ist - in dieser Phase wird das Product Backlog erstellt und priorisiert. Wenn Sie ohne das Design angefangen haben, sollte klar sein, was ohne das Design möglich ist und was nicht ...

Wenn Sie improvisieren müssen, während das Design zwischen dem Kunden und der Bestellung "stößt", muss Ihre Bestellung das Team über neue Funktionen informieren, sobald diese angezeigt werden: Dies ist die Bedeutung von "Flexibilität" in Scrum - passen Sie sich an die laufenden an Lage. Das Entwicklungsteam, der Scrum Master und der Product Owner müssen permanent kommunizieren, da sonst keine Echtzeitreaktion auf Änderungen erfolgt.

Etwas mehr Training kann nicht schaden ... Vielleicht wäre die Zusammenarbeit mit dem Designer eine Gelegenheit für Sie, neue UX-Kenntnisse zu erwerben? ... das beobachtet, dass das Glas halb voll statt halb leer ist :))