Ich habe ein neues Entwicklungsteam und möchte Story Points für allgemeine Schätzungen verwenden.
Aber ich habe zwei Probleme:
Beim Product Backlog Refinement gehen wir also davon aus, dass in den meisten Fällen eine konkrete Story von einem konkreten Entwickler umgesetzt wird. Offensichtlich wird nur dieser Entwickler seine Story einschätzen (weil nur er das erforderliche Wissen hat).
Aber Story Point sind messbare Einheiten für das gesamte Team, nicht für eine einzelne Person im Team. Wenn wir die Geschichten eines konkreten Entwicklers schätzen, ist ein Story Point eines Entwicklers nicht dasselbe wie ein Story Point eines anderen Entwicklers.
Die Frage ist also:
Der Grund für die Verwendung von Story Points ist, dass wir damit die Kapazität des Teams ermitteln können.
Die Frage, die Sie sich stellen müssen, ist, wie das Team, das Sie beschreiben, seine Kapazität am besten ausarbeitet.
Wenn man Grenzen zwischen den Disziplinen erzwingt, dann hat man tatsächlich mehrere Fähigkeiten und nicht nur eine.
Angenommen, das Team besteht aus 5 Entwicklern. 2 Entwickler können nur an Geschichten arbeiten, die sich auf die Datenbank beziehen. 1 Entwickler kann nur am Frontend arbeiten und 2 andere Entwickler können nur an den Webdiensten arbeiten.
In dieser Situation hat das Team eine Kapazität für Datenbankarbeit, eine Kapazität für die Frontend-Entwicklung und eine Kapazität für Webdienste. Das ist noch bevor wir anfangen, über Tests zu sprechen. Gibt es nur einen Tester, der an jedem Bereich arbeiten kann? Führen die Entwickler die Tests durch?
Die Schätzung in Scrum funktioniert am besten, wenn wir davon ausgehen, dass die Teammitglieder an jeder Story arbeiten können. Sie können an einigen Arten von Geschichten besser arbeiten als an anderen, aber sie können immer noch an allen Arten von Geschichten arbeiten. Wenn ein Entwickler nicht weiß, wie man etwas macht, kann er sich schulen lassen oder sich mit einem Entwickler zusammentun, der weiß, wie es geht. Auf diese Weise wird das Wissen im Team geteilt.
Ich würde Ihnen empfehlen, diesen Ansatz für den Wissensaustausch zu übernehmen und jedes Teammitglied bei jeder Geschichte zu schätzen. Sie werden feststellen, dass Entwickler Storys, mit denen sie nicht vertraut sind, hoch und Storys, die sie gut verstehen, niedrig einschätzen. Das ist in Ordnung, lassen Sie das Team einfach zu einer Konsensschätzung kommen, die die Eingaben aller Teammitglieder enthält. Die Art und Weise, wie die Geschwindigkeit berechnet wird, da ein gleitender Durchschnitt dazu neigt, solche Dinge im Laufe der Zeit zu kompensieren.
Wenn das Team nicht funktionsübergreifend werden möchte, sollten Sie besser auf Aufgabenebene als auf Story-Ebene schätzen. Möglicherweise stellen Sie fest, dass die Schätzung in idealen Stunden bei diesem Ansatz nützlicher ist als Story Points.
Story Points sind immer eine gute Idee, die Herausforderung besteht darin, eine Aufgabe zu finden, die alle Teammitglieder verstehen und die dann als „Referenzpunkt“ fungieren kann.
Bei der Schätzung einer Geschichte auf der Grundlage dieser Referenzaufgabe sollte die Person, die über fundierte Kenntnisse zu dem Thema verfügt, nach bestem Wissen und Gewissen erklären, welche Faktoren in der zu schätzenden Geschichte eine Rolle spielen, damit die anderen Teammitglieder dies tun können Schätzen Sie angemessen ab, wie komplex sie im Vergleich zur Referenzaufgabe ist.
Am Anfang wird dies schwierig sein, da das domänenübergreifende Wissen noch begrenzt ist, aber wenn das Team weiter zusammenarbeitet, werden Sie feststellen, dass die Genauigkeit der Schätzungen schnell zunimmt. Das setzt voraus, dass Sie nach jedem Sprint ein retrospektives Meeting abhalten, bei dem sich das Team etwas Zeit nimmt, um zu analysieren, was während des Sprints gut und was schief gelaufen ist, wobei ein Teil davon die anfänglichen Schätzungen der Stories mit der tatsächlich benötigten Zeit vergleicht vervollständigen sie.
Dies ist wahrscheinlich nicht Ihre Situation, aber dies ist ein inhärentes Problem mit Spieleentwicklungsteams (mein Haupterfahrungsbereich), da es normalerweise keine Überschneidungen in den Fähigkeiten gibt und niemals geben wird, wenn das Projekt größer als ein paar Scrum-Teams ist. In diesen Fällen habe ich in jeder Abteilung separate Story-Point-Schätzungen verwendet, aber es gibt ein paar Nachteile. Erstens kann es die Silo-Mentalität und -Kultur (schlecht) verbessern, und zweitens macht es die Planung sauberer Sprints und Veröffentlichungen viel rätselhafter. Ich muss oft "kleine Lücken füllen" mit möglichen Überschneidungen wie Tests oder Shadowing, um zu erfahren, wie die anderen Abteilungen arbeiten, oder persönliche Ziele zu erreichen. Positiv ist, dass es schnell zeigt, wo Teile des Release-Plans schief sind und/oder Sie möglicherweise Expertenkapazitäten benötigen.
Abgesehen davon (und bevor Sie mich ablehnen :) ), würde ich den Rat von Barnaby Golden empfehlen, mit Betonung auf einem konkreten und greifbaren Plan zum Cross-Training und Paaren mit dem Ziel gemeinsamer Einzelwertschätzungen.
Dies ist ein weit verbreiteter Irrtum. Die Leute denken, dass ein funktionsübergreifendes Team ein Team ist, in dem jede Person alle erforderlichen Fähigkeiten besitzt, um die Arbeit zu erledigen.
Ein funktionsübergreifendes Team hat Mitglieder mit unterschiedlichen Fähigkeiten, aber das bedeutet nicht, dass jedes Mitglied über alle Fähigkeiten verfügt.
Mike Cohn sagte einmal:
Wenn mein Team den weltbesten Datenbankentwickler umfasst, möchte ich, dass diese Person erstaunliche Dinge mit unserer Datenbank tut. Ich brauche nicht den weltbesten Datenbankentwickler, um JavaScript zu lernen.
Mein Team besteht normalerweise aus 2 BE-Entwicklern, 2 FE-Entwicklern und 2 QA. Jedes Teammitglied ist in den Schätzprozess eingebunden. Wir machen Scrum Poker komplett. Alle machen mit und geben Input, über die finalen Punkte entscheiden wir im Team.
Das einzige, was Sie beachten müssen, ist:
Danny Schoemann
jmort253
Sergej Kudrjawzew
Sergej Kudrjawzew