Aus Nutzersicht scheinen unsere Geschichten klar. Aus technischer Sicht sind unsere Geschichten etwas zu weit gefasst und müssen in Unteraufgaben aufgeteilt werden. Das ist in Ordnung, aber jedes Teammitglied hat eine Spezialität. Sie können nur wirkliche Schätzungen für jede Spezialität liefern (z. B. Daten vs. Backend vs. Frontend). Wir haben auch eine andere Kapazität für jede Spezialität in jedem Team und die Story Points bedeuten möglicherweise nicht dasselbe für jeden Spezialbereich.
Darüber hinaus scheint es, dass User Stories im Allgemeinen nicht vor dem Ende des Meilensteins abgeschlossen werden, da jeder an verschiedenen Dingen arbeitet und es erst am Ende zusammenkommt.
Also meine Fragen sind:
... die Story Points bedeuten möglicherweise nicht für jeden Fachbereich dasselbe
Wenn ein Scrum-Teammitglied eine Story schätzt, schätzt es nicht nur seinen Beitrag zur Story. Was sie tun, ist, dem gesamten Team zuzuhören und auf der Grundlage der Diskussion über den Umfang der Geschichte zu entscheiden.
Beispielsweise kann für eine bestimmte Geschichte die Frontend-Entwicklung einfach, die Backend-Entwicklung jedoch schwierig sein. Die Back-End-Entwickler beschreiben, warum es für das Team schwierig ist und das gesamte Team daher eine größere Story-Größe einschätzen würde.
Ich habe ein Teammitglied dies zu einem Kollegen in einem Planungsmeeting sagen lassen:
„Du hast gerade gesagt, dass das wirklich schwierig ist, aber dann hast du eine 3 geschätzt. Sollten wir unsere Schätzung nicht erhöhen, wenn es wirklich so schwierig ist?“
Mit diesem Ansatz ist es Spezialistenteams möglich, gemeinsam und konsistent zu schätzen.
Wenn Sie jedoch ein Team von Spezialisten haben, muss die Sprintkapazität sorgfältig ausgearbeitet werden. Ich habe gesehen, dass Teams wie dieses mit Story-Point-Schätzungen beginnen, dann aber zeitbasierte Schätzungen für technische Teilaufgaben vornehmen. Auf diese Weise können sie überprüfen, ob ein bestimmtes Teammitglied nicht überlastet wird. Beispielsweise kann das Team eine Geschwindigkeit von 30 Story Points haben, aber eine bestimmte Auswahl an Storys, die sich auf 30 summiert, kann eine Disziplin überlasten.
Stories, die am Ende eines Sprints abgeschlossen werden, sind in der Regel ein Zeichen für große Stories. Versuchen Sie, sie so weit wie möglich aufzuschlüsseln, während Sie dennoch einen gewissen Geschäftswert pro Geschichte beibehalten.
Barnaby sagte:
Wenn Sie jedoch ein Team von Spezialisten haben, muss die Sprintkapazität sorgfältig ausgearbeitet werden. Ich habe gesehen, dass Teams wie dieses mit Story-Point-Schätzungen beginnen, dann aber zeitbasierte Schätzungen für technische Teilaufgaben vornehmen.
Das ist unsere Situation, und das tun wir. Ein Teil unserer Sprint-Planung beinhaltet die Koordination, um sicherzustellen, dass alle ungefähr zur gleichen Zeit an der gleichen Story arbeiten und dass die Aufgaben aufgeteilt wurden, um sicherzustellen, dass niemand andere blockiert. Wir haben ein ungefähres Gefühl für die Kapazität jeder Spezialität während des Sprints und wählen die Geschichten entsprechend aus.
Auch System-Handshakes (also Stellen, an denen wir einzelne Fachbeiträge integrieren können) identifizieren wir möglichst früh, insbesondere über APIs hinweg, auch wenn das bedeutet, einiges an Innereien vorzutäuschen. Dies hilft, das Problem „Kommt nicht bis zum Ende zusammen“ zu vermeiden. (Ihre Entwickler möchten dies möglicherweise nicht tun; meine nicht. Ich habe darauf bestanden und wir alle sehen jetzt den Wert darin, zu versuchen, diese Schleifen frühzeitig zu schließen, damit wir Probleme frühzeitig erkennen können.)
Sie können nur wirkliche Schätzungen für jede Spezialität liefern (z. B. Daten vs. Backend vs. Frontend).
Dagegen würde ich mich wehren. Meine Standardrede ist "ok, aber Sie haben gesehen, wie lange andere Teams gebraucht haben, um etwas Ähnliches zu tun, also schätzen Sie auf dieser Grundlage." Dies fördert die Eigenverantwortung des Teams für den gesamten Sprint und kann auch bei der Schätzung und dem Wissenstransfer nützlich sein, z.
SpecialtyA Dev, Schätzen der SpecialtyA-Aufgabe: Ich würde das eine 4 nennen. SpecialtyB Dev: Wirklich? Ich hatte das als 7, weil es so klingt, als wäre OtherThing, das du gemacht hast, eine 7 gewesen. SpecialtyA Dev: Oh, hm, du hast recht, ich habe etwas vergessen. Oder: SpecialtyA Dev: Nun, es ist ähnlich, aber die Implementierung von OtherThing hat zum ersten Mal den ganzen schwierigen Teil erledigt. Jetzt können wir einfach einige dieser Maschinen wiederverwenden, deshalb ist es eine 4.
Ich mag diese Frage sehr, denn wie oft habe ich es mit Teams zu tun gehabt, die mit ähnlichen Problemen zu kämpfen hatten. Ihre Frage weist auch auf eine Handvoll sehr wichtiger agiler Entwicklungskonzepte hin, wie das Schätzen anhand von Story Points, Velocity und die Definition of Done.
Ich werde so knapp wie möglich antworten.
Wie definieren Sie User Stories, die bis zum Ende des Sprints abgeschlossen werden können?
User Stories sind von Natur aus breit gefächert, um das entstehende Design, die persönliche Zusammenarbeit im Team zu fördern und, was noch wichtiger ist, um Verschwendung zu vermeiden, die im traditionellen Projektmanagement üblich ist, wo Anforderungsdokumente vorbereitet und abgezeichnet werden, bevor irgendetwas anderes getan wird.
Ermutigen Sie also Ihren Product Owner, User Stories so breit wie jetzt zu schreiben. Stellen Sie jedoch sicher, dass Sie die Produkt-Backlog-Verfeinerung während des gesamten Sprints fördern, sodass vor dem nächsten Sprint-Planungsmeeting die hochwertigen User Stories (von denen der Product Owner hofft, dass sie während des bevorstehenden Sprints geliefert werden) mit genügend Details zerlegt werden, um die Vereinbarungen des Teams zu erfüllen Definition von Ready (DoR) . Während der Sprint-Planung zerlegt das gesamte Team dann jede der vom Entwicklungsteam ausgewählten User Stories weiter, das natürlich die technischen Unteraufgaben wie UI-Design, Back-End-Design und so weiter hinzufügen würde.
Wie bei DoR muss sich das Team auch auf die Definition of Done (DoD) einigen . Stories, die am Ende des Sprints die Definition von Done erfüllen, gelten als „done“, alles andere geht zurück in das Product Backlog und wird möglicherweise vom Product Owner je nach Geschäftsprioritäten erneut ausgewählt. Offensichtlich kann jede Geschichte auch ein Akzeptanzkriterium haben, das wie das DoD erfüllt werden müsste.
Wie funktioniert das Zeigen im Team, wo jeder eine Spezialität hat?
Erstens nehme ich an, dass Sie mit dem Zeigen die "Schätzung" anhand von Story Points meinen. Wenn nicht, kommentieren Sie bitte und ich werde meine Antwort entsprechend aktualisieren.
Bei Agile erfolgt die Schätzung also nicht wie bei herkömmlichen Ansätzen anhand von Mannstunden oder Manntagen. Story Points sind abstrakt, wiederum beabsichtigt. Es gibt viele Vorteile für die Verwendung dieser Art der Schätzung, aber zwei davon gefallen mir:
Lassen Sie also während der Sprintplanung das Team gemeinsam schätzen. Es spielt keine Rolle, ob es richtig oder falsch ist. Es gibt viele Techniken, um dies zu ermöglichen, wobei Planungspoker die gebräuchlichste ist.
Wie können Sie in diesem Fall wiederum dieses Zeigen mit Geschwindigkeit verwenden?
Die Geschwindigkeit ist ziemlich einfach zu berechnen. Sie nehmen die Summe der abgeschlossenen Story Points im letzten Sprint (oder Durchschnitt der letzten paar Sprints) und das war's. Auch hier soll die Geschwindigkeit dem Team lediglich einen Indikator dafür liefern, wie viel Arbeit es pro Sprint bewältigen kann. Wenn sie mehr tun, großartig. Wenn sie weniger tun, lassen Sie sie das untereinander besprechen. Nichts anderes.
zusätzliche Kommentare
Ihr Ziel als Scrum Master sollte es sein, Ihr Team zu ermutigen, immer funktionsübergreifender zu werden. Das ist außerordentlich schwierig, aber nur ein Team mit minimalen Spezialisten wird wirklich effizient und fast ohne Verschwendung. Sie sollten über ScrumFall lesen , ein häufiges Problem in Scrum/Agile-Teams, das Sie von Ihrem Team fernhalten sollten.
dKen
Gummiente