Ich habe mehrere Entwicklungsteams, die vor 6 Monaten von Stunden zu Story Points gewechselt sind. Seitdem sind bei der Verwendung von Story Points mehrere Probleme aufgetreten, und ich hoffe, Sie können mir und uns helfen:
Bei der Verwendung von Stundenschätzungen hätten wir auf jedes Problem zurückblicken und sagen können, ob wir uns zu viel Mühe gegeben haben und wie die aktuelle Situation dieses Problems innerhalb des Sprints ist. Der Wechsel zu Story Points erlaubt uns keine solche Granulierung, und wir können den Aufwand, den wir für ein Problem mit X Story Points aufgewendet haben, nicht zurückverfolgen. Ist das der Sollzustand? Wie kompensieren wir diesen Mangel an Daten?
Wie bereits erwähnt, haben wir beim Versuch, Sprints erfolgreich abzuschließen, in jedem Daily Stand-Up nach unseren Problemen gesucht, die gemeldete Zeit im Vergleich zur verbleibenden Zeit und konnten bestimmen, wie viel Zeit wir einplanen müssen, ob wir länger bleiben müssen oder was auch immer ... Jetzt haben wir das Gefühl, dass wir innerhalb des Sprints nicht zu allen Themen Bescheid wissen, und der Teamleiter, der sein Team pushen will, weiß nicht, wie er das anstellen soll.
Offensichtlich werden nicht alle Vorgänge in einem bestimmten Sprint erledigt. Aber jetzt im nächsten Sprint, da wir die Story Points-Schätzungen nicht ändern – woher wissen wir, wie viel von einem Problem noch übrig ist? Es scheint, dass wir es wissen müssen, um dem Sprint die angemessene Menge anderer Probleme hinzuzufügen, die der Kapazität des Teams entsprechen.
Gibt es eine bestimmte Praxis, die Verwendung von Story Points für die Aufwandsschätzung und Stunden für das Sprintmanagement zu kombinieren?
(1) Neben der Verwendung von Story Points zur Schätzung können Sie auch die für jedes Problem aufgewendete Zeit nachverfolgen. Nichtsdestotrotz dienen Story Points zum Schätzen der Komplexität und nicht der Zeit. So oft wird 1 Story Point für Geschichten verwendet, die denen, die zuvor gemacht wurden, sehr ähnlich sind und bei denen das Team genau weiß, wie es geht. Egal, ob es sich um eine winzige Änderung oder ein neues Feature mit viel Code handelt. Der aktuelle Stand dieses Issues im Sprint sollte noch einsehbar sein, denn im Daily kann der Entwickler, der daran arbeitet, in der Regel eine Einschätzung abgeben, wie viel von diesem Issue bisher erledigt ist.
(2) Normalerweise sollte ein Team keine zusätzlichen Stunden investieren, um das Sprintziel zu erreichen. Das Team sollte in einem Tempo arbeiten, das es langfristig mithalten kann. Wenn Sie z. B. einen zweiwöchigen Sprint haben, sollten die Issues / User Stories eine Größe haben, dass jeder Entwickler einen Haufen davon angehen kann und jede davon im Idealfall nicht länger als einen oder vielleicht ein paar Tage dauern sollte. Auf diese Weise können Sie den Sprint-Fortschritt ziemlich einfach verfolgen, indem Sie den Prozentsatz der User Stories mit dem Prozentsatz der Zeit vergleichen, die im Sprint vergangen ist. Über die offenen Punkte können die Entwickler im Daily eine Einschätzung abgeben, wie viel Arbeit noch übrig ist. Ich kenne also Ihre User Stories/Probleme nicht, aber vielleicht besteht eine Möglichkeit darin, sie in kleinere Stücke/User Stories zu zerlegen und dadurch die Transparenz und Nachvollziehbarkeit zu verbessern.
(3) Das Ziel in Scrum sollte immer sein, alle Tasks im Sprint Backlog abzuschließen. Es kann vorkommen, dass manchmal ein oder zwei Aufgaben nicht abgeschlossen werden können, aber das sollte nicht allzu oft der Fall sein. Wenn eine Aufgabe im Sprint nicht abgeschlossen wird, wird sie neu geschätzt und am Ende des Sprints in das Product Backlog zurückgenommen. Normalerweise wird es dann direkt zum nächsten Sprint gebracht.
(4) Nach jedem Sprint können Sie die Velocity Ihres Teams berechnen, indem Sie die Anzahl der innerhalb des Sprints erreichten Story Points durch die Anzahl der Entwicklertage im Sprint dividieren. Diese Geschwindigkeit (normalerweise gemittelt über die letzten paar Sprints) kann dann als Richtschnur dafür genommen werden, wie viele Story Points für den nächsten Sprint zu nehmen sind. Trotzdem sollte man bei der Sprintplanung dem nicht blind folgen, sondern berücksichtigen, ob die Stories groß oder klein sind etc.
Daniel