Sollten individuelle Fähigkeiten in Story Points berücksichtigt werden?

Mein Verständnis der Story-Schätzung war, dass man die Größe einer Story so schätzen sollte, wie es für einen imaginären, durchschnittlichen Entwickler der Fall wäre - ein bisschen wie das gesetzliche Konzept des "vernünftigen Zuschauers". Das heißt, Sie sollten die Größe der Geschichte nicht schätzen, vorausgesetzt, Sie müssen es tun .

Um ein Beispiel zu nennen: In meinem vorherigen Job war ich Teil eines Teams, in dem ich mit Abstand der selbstbewussteste Ruby-Entwickler war. Meine Teamkollegen schätzten Ruby-bezogene Geschichten routinemäßig weitaus größer ein als ich, mit Argumenten wie: "Nun, ich weiß nicht, wie X in Ruby funktioniert, daher würde ich ewig brauchen, um dies zu tun."

Mein Argument gegen das kommt von der Tatsache , dass Sprint - Planung ist , wo das Team die Fähigkeit ins Spiel kommt. Das ist das richtige Forum, um zu sagen: "Unsere Kapazität für diesen Sprint wird etwas geringer sein als gewöhnlich, da die meisten Aufgaben auf Ruby basieren und wir nur einen starken Ruby-Entwickler haben." Wenn dies während der Schätzung berücksichtigt wird, würde sich dieser Aspekt verdoppeln.

Ich würde mich über maßgebliche Referenzen in Antworten freuen, aber einfache Meinungen wären auch großartig.

Story Points sind eine relative Schätzung. Doppelte Punkte bedeuten also doppelt so viel Aufwand. Relative Schätzungen unterliegen weniger Schwankungen des Qualifikationsniveaus. Die Frage ist nicht so sehr, wie viel Zeit Sie für 1 Punkt benötigen würden, sondern dass 2 Punkte 2-mal mehr potenziellen Aufwand erfordern. Die Fähigkeitsstufe könnte wichtiger sein, wenn Sie ideale Tage anstelle von Story-Punkten benötigen, da Sie von einer individuellen Produktivität ausgehen.

Relative Schätzungen sind robuster. Darüber hinaus sollte die Bewertung der Story Points nicht von einer Person durchgeführt werden, sondern aus einer gemeinsamen Teamarbeit resultieren . Für weniger komplexe Geschichten gibt es normalerweise eine schnelle Einigung. Für anspruchsvollere Geschichten wird das Team ein Ergebnis liefern, dem die meisten Mitglieder zustimmen und daher implizit das kollektive Qualifikationsniveau des Teams berücksichtigen.

Schließlich wird die Bewertung der Story zu einem Zeitpunkt durchgeführt, an dem die Aufgaben innerhalb des Teams nicht unbedingt bereits entschieden sind. Dies ist ein weiteres Argument, um das individuelle Qualifikationsniveau nicht zu berücksichtigen. Für die Sprintplanung verwenden Sie die Story-Point-Kapazität des Teams. Diese Zahl entwickelt sich basierend auf den tatsächlichen Leistungszahlen, sodass sie sich selbst an das globale Qualifikationsniveau Ihres Teams anpasst.

Zusammenfassend sollte die individuelle Fähigkeit bei der Schätzung nicht berücksichtigt werden. Aber selbst wenn dies aufgrund der kollektiven Schätzungen und der Robustheit des relativen Ansatzes geschehen würde, wäre dies nicht so wichtig.

Die kanonische Antwort lautet, dass Sie die Schätzungen pro Entwickler nicht ändern sollten. Das würde bedeuten, dass Sie pro Sprint Tonnen mehr Punkte erzielen als Ihre Kollegen, und das ist in Ordnung, da Punkte die Geschwindigkeit des Teams messen , nicht Entwickler. Unternehmen können abschätzen, wie viel das Team produzieren wird, um grobe Erwartungen an die Lieferung zu erfüllen, und alles ist großartig.

Dies verursacht jedoch in der Praxis alle möglichen Probleme. Was passiert, wenn Sie diese Woche im Urlaub sind? Was passiert, wenn die Überprüfungszeit abläuft und Sie feststellen, dass Sie 200% der durchschnittlichen Story-Punkte für 110% des durchschnittlichen Gehalts produzieren? Was passiert, wenn Unternehmen anfangen zu glauben, dass die Teamgeschwindigkeit geteilt durch die Menschen tatsächlich eine genaue Annäherung ist? Was passiert, wenn das Unternehmen feststellt, dass Sie viel mehr Fehler produzieren als Ihre Kollegen (während Sie ignorieren, dass Sie viel mehr Funktionen produzieren)? Was sind "mundgerechte" Geschichten, wenn Menschen so unterschiedliche Bisse haben?

Was ich in meiner Karriere festgestellt habe, ist, dass es größtenteils keine Rolle spielt. Der Prozess ist da, um Ihnen zu dienen, nicht umgekehrt. Wenn Ihre Organisation beurteilen muss, ob Entwickler überlastet sind, sind Story-Punkte pro Entwickler eine gute Lösung. Wenn Ihre Organisation die Teamgeschwindigkeit messen muss, liefern dev-agnostische Story-Punkte ein klareres Bild. Dennoch sind sie immer eine Annäherung und werden immer missbraucht und falsch interpretiert.

Am Ende sind sie Punkte für einen erfundenen Prozess, den Sie an Ihre Umgebung anpassen müssen .

TL; DR
Wir sollten immer davon ausgehen, dass nur kompetente Entwickler einer bestimmten Story zugeordnet werden.

Kompetenz (oder deren Fehlen) ist keine Beleidigung. Es ist einfach ein vernünftiges Maß für die Fähigkeiten eines Entwicklers, der weder zurückbleibt noch außergewöhnlich erfahren ist.

Dies kann eine Frage des Ansatzes eines bestimmten Unternehmens sein. Ich habe gesehen, dass Unternehmen Schätzungen auf bestimmte Entwickler zuschneiden. Ich habe auch Unternehmen gesehen, die ein System erzwungen haben, bei dem drei zufällig ausgewählte Entwickler Story-Schätzungen vornehmen, bevor sie der Aufgabe fast zufällig einen Entwickler (nicht einen der ersten drei) zuweisen.

Jedes System kann funktionieren, jedes System kann ausfallen. Die Frage ist nicht so sehr, welches System besser ist, sondern welche Mängel das Unternehmen beheben kann / will .

Grundsätzlich sollte die Lernzeit für das Erlernen der Sprache / des Frameworks nicht berücksichtigt werden. Kleinere Tangente: Obwohl sie in einer idealen Welt nicht existieren sollten, sollte die Lernzeit für projekt- oder geschichtenspezifische Hindernisse einbezogen werden.

Es gibt viele Gründe dafür, aber ich glaube, dieser Ansatz ist im Allgemeinen eine bessere Wahl, da er der Absicht , eine Arbeitsbelastung abzuschätzen, treu bleibt . Dies könnte eher eine Frage meiner Meinung als eine Objektivität sein. Ich kann nicht sicher sagen.

Die Lernzeit ist persönlich . Dies gilt für einen bestimmten Entwickler, der an einer bestimmten Technologie arbeiten muss. Dies ist für die Beurteilung der Arbeitslast einer User Story nicht relevant, da sich eine User Story nur auf den Anwendungsbereich (und die verwendete Technologie) bezieht.

Die Lernzeit ist im Allgemeinen nicht gestapelt. Nehmen wir an, unser Rookie weiß wenig über C # und wir schätzen, dass er drei zusätzliche Tage benötigt, um die Umgebung herauszufinden, bevor er die Arbeit erledigen kann. Wie in vielen Unternehmen, in denen ich gearbeitet habe, üblich, befinden wir uns jetzt in einer Besprechung, in der wir voraussichtlich mehrere User Stories (einzeln) schätzen werden. Nehmen wir zum Beispiel an, wir haben drei Geschichten zu behandeln.

• Fügen wir jeder Geschichte drei Tage hinzu ? Wenn alle drei Geschichten einen ähnlichen technischen Fokus haben, bedeutet dies, dass der Anfänger die zusätzliche Zeit für die zweite und dritte Geschichte nicht benötigt. Wir haben die Arbeit um sechs Tage überschätzt.
• Fügen wir jeder Geschichte einen Tag hinzu? Das ist auch nicht richtig. Wenn wir den Rookie nur einer von drei Geschichten zuordnen , haben wir ihm zwei benötigte Tage Lernzeit gekürzt. und wir haben anderen Entwicklern zwei unnötige Tage Lernzeit eingeräumt.
• Fügen wir einer Geschichte drei Tage hinzu? Wie können wir garantieren, dass diese Geschichte vor den beiden anderen behandelt wird? Der springende Punkt beim Erstellen separater User Stories ist, dass die Storys normalerweise unabhängig voneinander angegangen werden können. Die Richtigkeit unserer Schätzung hängt nun sowohl von der Annahme ab, dass unser Anfänger die Arbeit erledigt , als auch von der Reihenfolge, in der er diese Aufgaben zugewiesen bekommt (wenn es darauf ankommt, z. B. wenn die kombinierte Arbeitsbelastung einen einzelnen Sprint übersteigt).

Hinweis :
Es gibt andere Fälle, in denen sich die Lernzeit stapelt, z. B. wenn sich die drei Geschichten zu sehr unterschiedlichen Themen entwickeln und unterschiedliche Fähigkeiten erfordern.
Um herauszufinden, ob dies der Fall ist oder nicht, müssten wir alle drei Storys gleichzeitig betrachten, was langsam gegen das Prinzip der unabhängigen User Storys verstößt . Wenn wir diese Schätzungen in separaten Besprechungen angegangen wären, möglicherweise mit verschiedenen anwesenden Entwicklern; Wir wären nicht in der Lage, die Überlappung zwischen den Geschichten genau einzuschätzen.

Da wir nicht garantieren können, welche Storys tatsächlich erstellt werden (der Kunde lehnt möglicherweise eine große Schätzung ab) und wer ihnen zugewiesen wird, ist es sinnlos, zu versuchen, einen bestimmten Entwickler zu berücksichtigen, der einer bestimmten Story zugewiesen wird. Es endet nur damit, das Wasser zu trüben.

Stattdessen sollten wir eine Schätzung der Arbeitsbelastung vornehmen, vorausgesetzt, der Rookie wurde bereits auf den neuesten Stand gebracht (und ist daher ein gleichwertiger Entwickler wie seine Mitarbeiter).
Eine solche Schätzung ist entwicklerunabhängig, und die Richtigkeit der Schätzung schwankt daher nicht, je nachdem, welcher Entwickler der Story zugewiesen wird.

Hinweis
Es ist immer noch wichtig zu erkennen, dass ein bestimmter Entwickler möglicherweise zusätzliche Zeit zum Lernen benötigt, bevor er eine bestimmte Geschichte angehen kann. Das ist immer noch eine sehr relevante Überlegung. Diese Überlegung sollte jedoch nicht mit der Geschichte verbunden sein , sondern vielmehr mit der Zuordnung dieses bestimmten Entwicklers zu dieser bestimmten Geschichte.

Aber zu Beginn kann dies von Unternehmen zu Unternehmen unterschiedlich sein. Einige Unternehmen sind möglicherweise nicht so aufgeregt über die Lernzeit (z. B. wenn der Entwickler zwangsläufig ohnehin lernen muss, mit der Technologie umzugehen). Andere verlassen sich möglicherweise stark auf die Genauigkeit dieser Schätzungen, da dies die Abrechnung mit einem Kunden beeinflusst.

Am Ende geht es darum, dein Gift zu pflücken. Keiner dieser Ansätze ist garantiert genauer als die anderen.

Dies ist ein komplexes Thema, und es gibt häufige Debatten zu diesem Thema. Ich mag das Konzept der "kanonischen" Meinung dazu nicht: Es gibt verschiedene Meinungen mit Wert. Es gibt jedoch unterstützende Werte, Prinzipien und Praktiken, die den Ansatz leiten sollten.

Das Folgende basiert auf meinen eigenen Meinungen, die ich seit über 10 Jahren mit Scrum-Teams zusammenarbeite. Aber es ist nur meine Meinung.

1. Story Points als Prognosemethode Die ursprüngliche Absicht von Story Points bestand darin, eine schnelle Methode zur Schätzung des Aufwands zu finden, um vorherzusagen, was ein Team in einem bestimmten Zeitraum leisten kann. Einige der "Leuchten" geben an, dass Punkte nur zur Vorhersage des längerfristigen Umfangs (z. B. über eine Version) und nicht zur Bestimmung der Kapazität auf Sprint-Ebene verwendet werden. Darüber hinaus besteht das Konzept darin, dass Teams "relative Größen" basierend auf historischen Werten anwenden (Aufwand X ähnelt Aufwand B, der 3 Punkte betrug). Dies beschleunigt den Schätzprozess, sodass Teams zukünftige Arbeiten nicht in detaillierte Arbeitspakete aufteilen und Stunden auf alle Aufgaben anwenden müssen. Hochleistungsteams bemühen sich, alle technischen Mitarbeiter zu sehr kompetenten Mitgliedern mit ähnlichen Fähigkeiten zu entwickeln. (Dieses Konzept wird in Punkt 4 näher erläutert.) Wenn dies erreicht ist, ist die individuelle Fähigkeitsstufe wirklich keine Variable bei der Größenbestimmung. ABER: Normalerweise dauert es ziemlich lange und es sind konzertierte Anstrengungen erforderlich, um dieses Ziel zu erreichen. SO ... was machen wir, bevor wir dort ankommen?

2. Arbeitsstunden bestimmen die Sprintkapazität: Laut denselben "Leuchten", die angeben, dass Punkte für Langzeitprognosen verwendet werden, schlagen sie auch vor, dass Arbeitsstunden zur Bestimmung der Sprintkapazität anstelle von Punkten verwendet werden. Meiner Meinung nach ist das in Ordnung, aber ich werde sagen, dass, wenn ich Trainerteams zu "High-Performance" verholfen habe, ihre ausgereiften Fähigkeiten so gemittelt wurden, dass sie genau bestimmen konnten, was sie in einem Sprint nur mit Story Points erreichen konnten . Auch dies kann ein Ziel sein, das wir anstreben, aber neuere Teams sind dafür nicht bereit. Daher finden Sie in einem einzelnen Sprint möglicherweise eine Story mit 2 Punkten, die 12 Arbeitsstunden und eine weitere mit 25 Stunden Aufwand umfasst. Also, was machst du? Einige Leute, die ich "agile Puristen" nenne, werden angeben, dass die Größe der Story (in Punkten) unabhängig von der Dauer sein sollte. Andere sind anderer Meinung. Lesen Sie die Logik zu Punkt 3 durch und sehen Sie, was Sie denken.

3. Story-Pointing im Konsens: Anwenden von Volumen, Unbekanntem, Komplexität, Wissen

Die Teams sehen sich also eine Arbeit an und müssen sich auf die Punkte einigen, die als Stellvertreter für das Maß an Aufwand dienen. Richtig? Unter der Annahme, dass alle Fähigkeiten gleich sind, ist ein Konsens leicht zu erreichen. Aber oft haben Teams einen Mann, der ein Java-Guru ist, einen anderen, der nicht so gut in Java ist (vielleicht war sie eine C # - oder .Net- oder Cobol-Person und lernt Java). Aufgabe X für Bob ist also sehr einfach. Für Jane ist es schwieriger.

Agile Teams versuchen, den Besitz von kollektivem Code zu fördern und das Fachwissen zu erweitern. Daher weisen wir Menschen normalerweise keine Geschichten aufgrund ihres Fachwissens zu: Wir bevorzugen Teams, die gemeinsam an Geschichten arbeiten und gemeinsam lernen. Dies entspricht dem Konzept "Verlangsamen, um zu beschleunigen": Wenn wir uns die Zeit nehmen, Jane Erfahrung mit Java zu vermitteln, während dies uns zunächst verlangsamen kann, werden wir später kompetentere Java-Entwickler haben. Wenn wir nur EINEN Java-Experten haben und jeder an seinen eigenen Fachgebieten arbeitet, schaffen wir eine Situation mit mehreren potenziellen "Fehlerquellen". Was passiert im Sprint, wenn 90% der Arbeit Java ist, Bob (unser Java-Experte) jedoch krank ist oder Urlaub macht? Durch die Erweiterung unserer Fähigkeiten beseitigen wir potenzielle Engpässe und reduzieren das Risiko. In diesem Sinne: Wenn sich das Team eine Geschichte ansieht, sollte es bei der Dimensionierung verschiedene Konzepte berücksichtigen. Sie können sich das Akronym VUCK vorstellen, um sich daran zu erinnern.

Volumen: Einige Bemühungen sind recht einfach, erfordern jedoch eine große Anzahl wiederholter Aufgaben. (Ich hatte einen Mann, der mehr als 50 Tabellen kopieren und neu formatieren musste, der sagte, es sei 1 Punkt, weil es einfach war. Aber nach Überlegungen stellte das Team fest, dass es zwar einfach, aber zeitaufwändig und mit einer großen Anzahl von Tabellen verbunden war bewegt und optimiert werden. Deshalb mussten wir die Punkte aufgrund des Arbeitsvolumens neu einstellen.)

Unbekannte: Manchmal DENKEN wir, wir wissen, was zu tun ist, aber wir identifizieren auch einige Unbekannte - diese repräsentieren RISIKEN . Dies bedeutet, dass wir möglicherweise auf unerwartete Probleme stoßen, die wir lösen, neu gestalten oder eine andere Lösung ausprobieren müssen.

Komplexität: Dieser ist ziemlich offensichtlich. Einige Lösungen sind technisch komplex. Wir wissen genau, was zu tun ist, aber es erfordert technisches Fachwissen. Komplexität birgt auch ein gewisses Risiko, nicht wahr? Selbst wenn wir alle die gleichen Fähigkeiten haben, impliziert die technische Komplexität, dass wir möglicherweise auf unvorhergesehene Herausforderungen stoßen. Also könnten wir diese Geschichte größer machen.

Wissen: Wissen wir WIRKLICH, was wir lösen? Manchmal sind sich die Kunden nicht ganz sicher, welche Lösung sie wollen, und wir experimentieren ein bisschen. Oder vielleicht hat noch niemand diese Lösung implementiert (neue Technologie, die noch nie zuvor verwendet wurde) und wir wissen nicht, was wir nicht wissen.

Meiner Meinung nach ist jede dieser Überlegungen tatsächlich ein Stellvertreter für eine längere Dauer. Einfache Geschichte, viel Volumen? Es wird länger dauern, oder wir müssen die Geschichte teilen. Unbekannte? Zusätzliches Risiko, Forschung, Experimentieren, es kann länger dauern oder wir müssen die Geschichte teilen. Komplex? Zusätzliches Risiko, Behebung von Fehlern, Neugestaltung usw., sodass es möglicherweise länger dauert. Sie wissen nicht, ob wir das erforderliche Wissen haben? Wir haben ein zusätzliches Risiko, müssen möglicherweise experimentieren usw., daher kann es länger dauern ...

Sehen Sie, wohin das führt? Während das Konzept der Story Points uns davon abhält, bei der Schätzung über die Dauer nachzudenken, wäre es andererseits unlogisch, eine 1-Punkt-Story zu haben, die wir in 4 Stunden fertigstellen können, und eine weitere 1-Punkt-Story, die einfach ist, aber dauern wird 2 Wochen.

4. Leistungsstarke Teams eliminieren Silos und Engpässe: Da Teams versuchen, alle Mitglieder zu verbessern, stellen sich manchmal weniger erfahrene Mitglieder neuen Herausforderungen oder sie koppeln Code, um Wissen auszutauschen und sich als Team zu verbessern. Wie bereits erwähnt, ist dies eine Voraussetzung, wenn das Team jemals echte High-Performance-Level erreichen wird.

Also, wenn Jane sich freiwillig bereit erklärt, diese Java-Anstrengung zu übernehmen, und das würde die Anstrengung 2x oder 3x der Dauer derselben Anstrengung machen, wenn Bob es tun würde, was machst du dann? Im Laufe der Zeit entschieden sich meine Teams für die Dimensionierung von Geschichten basierend auf dem Aufwand (LOE) / VUCK für die Personen, die an dem Aufwand arbeiten. Für Bob, den Team-Guru, macht es keinen Sinn, "das ist eine 1" zu sagen, wenn es für Jane nicht einfach ist und eine Woche dauert, bis sie abgeschlossen ist. Außerdem benötigt Bob etwas Zeit für die Paarcodierung und Codeüberprüfung. Daher haben wir diese Punkte erhöht, um den tatsächlichen LOE widerzuspiegeln. Das nächste Mal, als eine ähnliche Geschichte kam, wurde aus einer 8 für Jane zuvor eine 5. Schließlich waren sich alle einig, dass es eine einfache 3 war. Zu diesem Zeitpunkt wussten wir, dass wir als Team wachsen würden.

TLDR

Nein, aber vielleicht nicht aus dem Grund, den Sie denken.

Lange Version

Viele der anderen Antworten haben erklärt, dass Story Points nur in Bezug auf andere Arbeiten berechnet werden sollten. Das ist absolut wahr. Als Geschichte Points , um die Schätzung Menge der Arbeit , anstatt die erforderliche Zeit um es zu vervollständigen dann macht es wenig Sinn auf einer Person zu geben Story Points basiert.

Betrachten Sie zum Beispiel (einer meiner Favoriten) Ihre Aufgabe "Dig a hole". Sie können dies entweder anhand der zu entfernenden Erdmenge oder der Zeit abschätzen, die Sie zum Entfernen der Erde benötigen. Mein Freund gräbt ein Ganzes mit einer Geschwindigkeit von 3 Metern pro Stunde. Ich habe einen großen mechanischen Bagger, damit ich 100 schaffen kann! Die einzige Konstante ist die Erdmenge - daher verwenden wir diese als Schätzeinheit.

Ein zweiter (und meiner Ansicht nach wichtigerer) Grund für die Einschränkung der Entwicklerfähigkeit bei der Schätzung von User Storys ist jedoch die Tatsache, dass fast jede User Story wahrscheinlich von mehreren Personen bearbeitet wird.

Möglicherweise haben Sie einen Architekten, einen Entwickler, einen Tester oder einen zweiten Entwickler, der die Benutzeroberfläche erstellt. Bevor Ihre User Story als Fertig markiert wird (idealerweise bereitgestellt und erledigt), haben viele verschiedene Personen daran gearbeitet. Plötzlich macht die Idee der Schätzung basierend auf dem betreffenden Entwickler wenig Sinn. Die einzige Möglichkeit, genau abzuschätzen, wie viel Aufwand das Team mit sich bringen wird, besteht darin, die Geschwindigkeit des Teams zu messen und die Arbeit für das Team zu schätzen.

Es gibt kein "Ich" im Team und absolut kein Ich in der agilen Planung!