In unserem Scrum-Team neigen die Teammitglieder dazu, zusätzliche Punkte bei der Schätzung hinzuzufügen, wenn es um einen „Lern“-Teil geht.
Hier ist ein einfaches dummes Beispiel. Nehmen wir an, alle Personen in einem Team sind Experten in C#, haben aber weniger Kenntnisse in C++. Sie haben die Aufgabe, Feature X in C# zu implementieren, und sie schätzen es auf 5 Punkte. Wenn sie gebeten würden, genau dasselbe in C++ zu implementieren, wäre die Schätzung sagen wir 8, weil sie einige Punkte hinzugefügt haben, um herauszufinden, wie es in C++ geht.
In unserem Team kommt es manchmal vor, dass für jede Aufgabe ein paar Leute nicht in diesem Bereich des Codes gearbeitet haben (da wir Besitzer von mehr als 1 Projekt sind), also fügen sie immer ein paar zusätzliche Punkte zum Lernen oder für den Kontextwechsel hinzu (wenn sie nicht längere Zeit in diesem Bereich gearbeitet haben) bei der Schätzung. Ist das richtig?
Zählen Sie Lernen zu Ihren Schätzungen hinzu?
Vielen Dank
Story Point wird für die Planung auf hoher Ebene verwendet. Wenn wir die User Story in Story Points schätzen, sprechen wir von der Produktivität des gesamten Teams .
Points Stories dienen nicht der genauen Messung, Story Points dienen der relativen Messung . Während wir Story Points verwenden, können wir sagen, dass diese Story größer oder schwieriger als eine andere Story ist, aber wir können nicht sicher sein, wie viel Zeit genau wir sie implementieren werden.
Beispiel: Sie haben 2 User Storys. Die Bereiche sind ungefähr gleich. Aber einer davon sollte auf C# und ein anderer auf C++ implementiert werden. Ihr Team besteht aus zwei C++-Entwicklern und nur einem C#-Entwickler. Daher wird User Story mit C#-Implementierung natürlich schwieriger für Ihr Team und sollte natürlich mit mehr Story Points bewertet werden.
Ich denke, dass das Hinzufügen von Punkten für den Kontextwechsel keine gute Methode zum Schätzen ist. Ich meine, die Aufgabe selbst wird dadurch nicht komplexer. Soweit ich das sehe, ist dies ein sehr typischer Fall, in dem die Schätzung aufgefüllt wird - absichtlich größere Werte angegeben werden, um später Stress oder Zeitdruck zu reduzieren.
Das Problem bei diesem Ansatz ist, dass Schätzungen verfälscht werden und die Messungen weniger genau sind. Ein besserer Weg wäre, die Komplexität für den Aufgabenwechsel nicht zu erhöhen, sondern eine geringere Geschwindigkeit zu messen, und möglicherweise können die Kosten des Kontextwechsels zu den Hindernissen hinzugefügt werden.
(Was das Lernen betrifft, stimme ich den vorherigen Kommentaren zu - wenn Sie etwas Neues lernen müssen, um Ergebnisse zu erzielen, wird die Aufgabe komplexer.)
Story Points sind ein relatives Maß für die Komplexität. Sie addieren sich zu einer Geschwindigkeit, die verwendet werden kann, um die DURCHSCHNITTLICHE Arbeitsbelastung zu bestimmen, die ein Team in einer Iteration bewältigen kann. Wenn eine Geschichte zusätzliches Lernen durch das Team erfordert, ist sie komplexer und kann höher eingeschätzt werden. Story Points sind eine Teammaßnahme, keine individuelle Maßnahme. Tappen Sie nicht in die Falle, die niedrigste Schätzung zu nehmen und die Arbeit dann der Person zuzuweisen, die sie niedrig geschätzt hat. Versuchen Sie, ein Team aufzubauen, das einem Pull-Modell anstelle eines Push-Modells folgt, damit die Teammitglieder Erfahrungen in allen Bereichen des Projekts sammeln und selbst entscheiden können, woran sie arbeiten. Kurzfristig kann dies der "Produktivität" schaden, aber langfristig wird ein Team mit breitem Domänenwissen, höherer Produktivität und geringerem Risiko, auf große technische Hindernisse zu stoßen, entstehen.
Wenn Sie 1 Entwickler haben, der lernen muss, und 1, der dies nicht tut, erhalten Sie zwei individuelle Schätzungen, die kombiniert werden müssen, um die Teamschätzung zu bilden. In diesem Fall empfehle ich Ihnen, sich für die höhere Schätzung zu entscheiden, da das Worst-Case-Szenario mit der höheren Schätzung darin besteht, dass die Arbeit vom erfahrenen Entwickler früher abgeschlossen wird und etwas anderes in die Iteration gezogen werden kann.
Wenn Sie sich dagegen für die niedrigere Schätzung entscheiden und der unerfahrene Entwickler am Ende die Geschichte macht, hat Ihr Team einfach zu viel zugesagt, und Sie setzen unrealistische Erwartungen an Ihren Kunden in dieser Iteration.
Die kurze Antwort ist nein, die Unterschiede zwischen den Fähigkeiten der Entwickler werden anhand der Velocity berücksichtigt und sollten sich nicht auf die Schätzung der Story Points auswirken. Es ist leicht, die Scrum-Konzepte von Punkten und Geschwindigkeit zu verwechseln, da Menschen oft darauf trainiert sind, in Zeiteinheiten zu schätzen (z. B. „Ich bin bis Donnerstag fertig“). Bei Scrum werden Schätzungen anhand von Größeneinheiten vorgenommen (z. B. „Das Rennen ist 100 Meter lang“). Die Teamgeschwindigkeit wird gemessen, indem beobachtet wird, wie viele Punkte ein Team während eines Sprints wiederholt absolvieren kann (z. B. „Der Athlet läuft 5 Meter pro Sekunde“). Wenn sich die Geschwindigkeit durch Geschicklichkeits- oder Prozessänderungen verbessert, werden Liefertermine berechnet (z. B. „Es wird wahrscheinlich 100/5 = 20 Sekunden dauern, um das Rennen zu beenden“).
Punkte schätzen
Versuchen Sie, die Planungspokermethode zum Schätzen von Geschichten zu verwenden. Dadurch wird das Problem behoben, auf das Sie stoßen, wenn zwei Teammitglieder die Aufgabe als „3“ bezeichnen, während ein anderes Teammitglied die Aufgabe als „8“ bezeichnet. Was Sie wollen, ist ein Konsens zwischen allen Teammitgliedern. Sie werden drei wichtige Schritte im Planungs-Poker-Verfahren bemerken:
Geschwindigkeit schätzen
Verwenden Sie Velocity, um die unterschiedlichen Fähigkeiten der Mitglieder Ihres Teams zu berücksichtigen. Denken Sie daran, dass der Story Point-Wert keine Schätzung der Zeit, sondern eher eine Schätzung der Entfernung ist . Es ist in Ordnung und wird erwartet, dass verschiedene Mitglieder Ihres Teams diese Distanz mit unterschiedlichen Geschwindigkeiten sprinten können. Um die Geschwindigkeit abzuschätzen, halten Sie einen laufenden Durchschnitt der in jedem Sprint abgeschlossenen Punkte aufrecht. Verwenden Sie den Velocity-Wert des Teams, um zu entscheiden, wie viele Storys in einem einzigen Sprint abgeschlossen werden können. Diese Kapazitätsgrenze berücksichtigt die Tatsache, dass verschiedene Teammitglieder Code mit unterschiedlichen Geschwindigkeiten schreiben (z. B. dass einige mehr lernen müssen als andere usw.).
Ja, machen wir.
Sie schätzen den Aufwand einer Geschichte. Wenn Sie die Geschichte auf verschiedene Aufgaben aufteilen, müssen Sie für die C++-Geschichte das Lernen als zusätzliche Aufgabe.
Dennoch weist der Product Owner der C++- und der C#-Story denselben Kundenwert zu. Bei der Sprint-Planung sollte das Team die C#-Story aufgrund des gleichen Werts, aber weniger Aufwands priorisieren.
Sie werden aus verschiedenen Gründen immer unterschiedliche Schätzungen von verschiedenen Personen erhalten. Sie brauchen nur eine einfache Möglichkeit, es zu Planungszwecken auf eine einzige Zahl zu reduzieren.
Ich habe festgestellt, dass es eine gute Methode ist, nur den Durchschnitt zu nehmen, um dies zu erreichen. Ihre oberen und unteren Schätzungen geben Ihnen eine Vorstellung von der Unsicherheit der Schätzung.
Der Versuch, die Schätzung in Unteraufgaben wie „Lernen“ oder „Kontextwechsel“ aufzuteilen, kann kontraproduktiv sein und erhöht normalerweise nur die Schätzung und die Unsicherheit
Einige historische Daten sollten Ihnen bereits eine Vorstellung davon geben, ob diese +2 Punkte irgendwie zutreffend sind oder nicht. Hast du das schon gemessen?
In diesen Fällen rate ich dem Team normalerweise, die Lernaktivität von der Produktionsaktivität zu trennen. Das Lernen erfolgt in einem Sprint, Schätzungen und Produktion im nächsten. Wenn Sie nicht über triviale Dinge sprechen, wird Ihnen das Hinzufügen eines Puffers wahrscheinlich keine Genauigkeit darüber geben, ob es tatsächlich 20 % oder 30 % oder 50 % mehr sein wird, und tatsächlich sind C ++ und C # zwei sehr unterschiedliche Sprachen ... Wenn sie nicht wissen, wie man dieses Zeug in C++ macht, könnte es so einfach wie C# oder viel komplexer sein.
Dan Dinu
Tob