Ich bin ziemlich neu bei Scrum und arbeite mit einer Gruppe von Kollegen an einem Projekt, um mehr darüber zu erfahren. Kurz gesagt, unser Projekt erstellt einfach eine Website für Touristen unseres Landes, auf der sie einfach Kurse in einer bestimmten Stadt erstellen oder nutzen können.
Was wir getan haben, ist über Benutzergeschichten nachzudenken (wir haben nicht wirklich UX-Forschung betrieben, also betrachten Sie diese Geschichten einfach als gültig), die für das, was wir machen wollen, relevant sind. Betrachten Sie zum Beispiel die folgende Geschichte:
Als Tourist möchte ich Kurse nach meinen Bedürfnissen gestalten.
Dies ist nur ein Beispiel, wir haben ungefähr 15 weitere Geschichten. Und da wir neu in diesem Prozess sind, haben wir Aufgaben von Geschichten definiert, die unserer Meinung nach besser zur Geschichte passen. Zum Beispiel müssen wir eine Anmelde-/Registrierungsseite erstellen, aber wir konnten keine Story dafür erstellen, also haben wir sie in die relevanteste Story aufgenommen. Es gibt also wenige Geschichten mit zusätzlichen Aufgaben. Und da wir diesen Ansatz verfolgt haben, haben wir tatsächlich die Aufgaben geschätzt und nein die Geschichten (etwas ein Hack?). Jetzt stehen wir vor dem Problem, dass wir ein Scrum-Tool verwenden müssen, um unsere Arbeit zu visualisieren. Wir haben uns für TargetProcess entschieden, das kostenlos ist. In diesem Tool werden den Geschichten offensichtlich Story-Punkte gegeben, während den Aufgaben eine Schätzung nach Stunde gegeben wird, und jede Aufgabe ist Teil einer Geschichte. Wenn wir nun an einer Aufgabe arbeiten müssen, können wir dies nicht tun, es sei denn, wir verschieben die gesamte Story in das Sprint-Backlog. Wenn also in einer Story nur eine Aufgabe für den Sprint geplant ist und der Rest nicht, würde dies zu einem Problem bei der Erstellung unserer Burndown-Diagramme führen. Meine Frage hier ist also, was können wir tun, damit dies funktioniert?
Es hört sich so an, als wären Ihre User Stories zu klobig und nicht unabhängig genug.
Ich würde empfehlen, dass Sie Ihr Backlog durcharbeiten und Ihre User Stories aufschlüsseln, indem Sie sie viel kleiner machen, während Sie gleichzeitig vollständig unabhängig oder so nah wie möglich unabhängig sind.
Es sollte zwischen 1-3 Tagen dauern, bis eine User Story fertig ist. Wenn es größer ist, müssen Sie es wahrscheinlich abbauen.
Dies ist eine großartige Ressource zum Aufschlüsseln von Benutzergeschichten: http://agileforall.com/wp-content/uploads/2018/02/Story-Splitting-Flowchart.pdf
Meiner Erfahrung nach ist das Schätzen von Aufgaben nicht so nützlich. Konzentrieren Sie sich auf das Erstellen und Schätzen kleiner unabhängiger Geschichten, und die Aufgaben sind optional, abhängig vom Entwickler, der die Geschichte aufgreift.
Die Aufgaben sind die technischen Aktivitäten, die ein Entwickler oder ein Entwicklerpaar ausführen wird, um die Akzeptanzkriterien der Story zu erfüllen. Es sollte nie Tage dauern, bis Aufgaben erledigt sind.
Willkommen in der Community, Amine.
Auch wenn es im Scrum-Leitfaden nicht ausdrücklich vorgeschrieben ist, ist die Art und Weise, wie Sie die Arbeit während der Verfeinerung aufteilen, ein wesentlicher Bestandteil des iterativen, inkrementellen Aufbaus Ihrer Lösung.
Es gibt eine Reihe von Modellen, die bei diesem Teil des Puzzles helfen. Eines der am weitesten verbreiteten Modelle ist das INVEST-Modell zur Aufschlüsselung von User Stories. Das INVEST-Modell besagt:
Eine gute User Story sollte sein:
"Ich" unabhängig (von allen anderen)
"N" verhandelbar (kein spezifischer Vertrag für Funktionen)
"V" änderbar (oder vertikal)
"E" stimulierbar (in guter Näherung)
"S"-Einkaufszentrum (um in eine Iteration zu passen)
„T“ estable (im Prinzip, auch wenn es noch keinen Test dafür gibt)
Vielleicht ist dies bereits Teil Ihres Prozesses, aber es ist auch wichtig, wirklich klare Akzeptanzkriterien für jede Geschichte zu haben. Diese Akzeptanzkriterien sollten von Ihrem Product Owner stammen und mit dem Team ausgehandelt werden, sobald sie der Meinung sind, dass die Kriterien über einen geringen Aufwand hinausgehen. Letztendlich verwaltet das Team seine Arbeit, aber solide Akzeptanzkriterien von einem Product Owner zu haben, ist der erste Schritt, um es zu befähigen, diese Arbeit zu besitzen.
Solide Akzeptanzkriterien helfen nicht nur bei der Verwaltung der Geschichte, sondern auch bei der Verwaltung der Aufgaben, die zur Vervollständigung der Geschichte erforderlich sind, was sich nach dem Problem anhört, das Sie zu lösen versuchen. Solange Ihre Geschichten gut INVESTIERT sind und gute Akzeptanzkriterien haben, sollte Ihr Team in der Lage sein, logische Nähte in Geschichten (also Aufgaben) zu finden, um dieses Problem viel besser zu bewältigen.