Ist es in Scrum obligatorisch, die Anzahl der Stunden zu schätzen, die benötigt werden, um jede User Story fertigzustellen, bevor sie in den Sprint aufgenommen wird? Oder sollten wir Planungspoker verwenden und Punkte statt Stunden verwenden?
Scrum schreibt eigentlich keinerlei Schätzung vor. Um ehrlich zu sein, schreibt es nicht einmal User Stories vor. Jeff Sutherland und Ken Schwaber haben hier http://www.scrumguides.org/ eine Kurzanleitung mit den Grundlagen von Scrum zusammengestellt – lesenswert.
Allerdings ist es für ein Team sehr schwierig, seine Sprintverpflichtungen konsequent zu erfüllen UND einige Risiken einzugehen, um innovativ zu sein und seine Produktivität schrittweise zu steigern, ohne die gesamte Arbeit, die in diesem Zeitrahmen zu erledigen ist, konsequent zu messen. Wenn Sie kleinere Stories oder Aufgaben, die Sie nicht Stories nennen, an denen Sie arbeiten werden, oder eine technische Untersuchung (Spike), die in einen Sprint aufgenommen werden, nicht schätzen, woher wissen Sie dann, wie viel Aufwand Sie haben? in nachfolgenden Sprints akzeptieren können? Woher wissen Sie, ob Ihr Team eine bestimmte Art von Geschichte (oder Aufgabe, Untersuchung oder was auch immer) immer gut im Griff hat (dh genaue Schätzung) oder nicht?
Ich bitte meine Teams, die gesamte Arbeit, die sie in einen Sprint stecken, zu schätzen, normalerweise mit Fibonacci-Story-Punkten. Es war sehr erfolgreich bei der Aufdeckung von Problemen mit schlecht geschriebenen User Stories, unbekannten Technologien, unzureichender Kommunikation und vielen anderen Problemen, die ein Team daran hindern, hoch zu funktionieren. Es kann mühsam sein, und Sie möchten nicht von der Genauigkeit von Schätzungen besessen sein oder ihren Wert übergewichten, aber die Schätzung ist ein großartiges Werkzeug, um Entwicklungsineffizienzen während des gesamten Prozesses zu beseitigen.
Story Points werden verwendet, um die relative Größe von Storys abzuschätzen (z. B. „Story A ist ungefähr doppelt so groß wie Story B“), aber dies sagt absichtlich nichts über die absolute Größe von Stories aus (z. B. „Story A dauert etwa 6 Stunden zu beenden, während Story B 3 Stunden dauert").
Planungspoker ist eine Möglichkeit, die für Schätzungen aufgewendete Zeit zu optimieren und Teammitglieder dazu zu bringen, Geschichten zu diskutieren, um zu einem gemeinsamen Verständnis der darin enthaltenen Aufgaben, offenen Fragen und Risiken zu gelangen.
Nicht alle Scrum-Teams verwenden Story Point Estimate und Planning Poker, obwohl beide von den meisten mir bekannten Experten empfohlen werden. Bei jeder Art von Projektplanung ist immer ein gewisses Maß an Schätzung erforderlich; Bei Scrum geht es darum, nur den absolut notwendigen Aufwand zu betreiben, um ausreichend gute Schätzungen zu erhalten, und diese dann während des Projekts nach Bedarf zu verfeinern und anzupassen. (Im Gegensatz zu anderen traditionellen Methoden, die möglicherweise mehr Wert auf Details und Genauigkeit der Schätzung legen, während die Endergebnisse in der Praxis den aufgewendeten Aufwand kaum rechtfertigen und dem Management nur ein falsches Gefühl der Sicherheit vermitteln.)
Wenn Sie also planen möchten, wann Sie das nächste Release liefern oder einen wichtigen Meilenstein erreichen können, müssen Sie die Velocity Ihres Teams abschätzen , dh wie schnell sie Storys im Durchschnitt fertigstellen können oder wie viele Storys sie auf einmal fertigstellen können Zeitrahmen (Sprint). Und damit das aussagekräftig ist, müssen Sie auch die relative Größe von Geschichten kennen. Aus diesem Grund wird Scrum-Teams empfohlen, Story Points zu schätzen.
Während der Sprintplanung verpflichtet sich das Team dann, eine bestimmte Anzahl von Storys innerhalb des bevorstehenden Sprints abzuschließen. Das ist besonders schwierig für unerfahrene Teams, die noch kein Gefühl für ihre Velocity haben, nicht gut im Einschätzen von Story Points sind und/oder eine schwankende Performance haben. Hier kann es helfen, eine zweite Schätzungsrunde zu durchlaufen, in der jede einzelne Aufgabe, die zu einer Geschichte gehört, in Stunden/Tagen geschätzt wird. Dies erfordert, dass das Team eine tiefere Diskussion über die Details der Geschichte führt, was ihm mehr Gelegenheit gibt, Schätzfehler auszugleichen und alle Faktoren zu berücksichtigen. Und am Ende können sie ihre Schätzung überprüfen, indem sie die Gesamtzeit addieren, die erforderlich ist, um die für diesen Sprint ausgewählten Stories abzuschließen.
Die Kehrseite des stundenlangen Schätzens ist natürlich, dass es mehr Zeit erfordert, das Team verlangsamt und möglicherweise nicht genug Wert bringt, um dies zu rechtfertigen. Erfahrene Teams können sich daher entscheiden, nur Story Points zu schätzen, nicht die Zeit. Aber in den frühen Phasen der Einführung von Scrum oder bei der Bildung eines neuen Teams kann es hilfreich sein, sowohl Stunden als auch Story Points zu schätzen.
In Scrum sind nur zwei Dinge obligatorisch: (1) Liefern Sie jeden Monat etwas aus, von dem Sie glauben, dass Sie es verkaufen können, und (2) schauen Sie sich an, wie Sie es gemacht haben, und versuchen Sie, sich darin zu verbessern.
Die "Story Points oder Stunden?" Diese Frage wird seit 15 Jahren heiß diskutiert. Viele Leute berichten, dass das bloße Zählen der Anzahl von Geschichten (weder Story Points noch Stunden) besser mit der langfristigen Kapazität korrelierte als jede andere Schätzungsmethode oder Skala, die sie verwendet hatten.
Wieder andere Leute empfehlen, die Kostenschätzungen von Geschichten wegzuwerfen und sich stattdessen darauf zu konzentrieren, die wertvollsten Geschichten so schnell wie möglich fertigzustellen. Wenn Sie darin gut werden, ist es viel weniger wichtig, ob Story 128 eine 2 oder eine 3 war.
Ihre Frage klingt so, als würden Sie es vorziehen, die Kosten für jede Geschichte nicht in Stunden zu schätzen, bevor Sie sie in den Sprint aufnehmen. Also tu es nicht. Ich wette mit dir, es wird gut.
Einfache Antwort: Nein. Scrum erfordert nicht, dass Sie eine Schätzung der Stunden angeben, die benötigt werden, um jedes Produkt-Backlog-Element fertigzustellen, bevor es in den Sprint aufgenommen wird.
Tatsächlich fordert Scrum Sie einfach auf, einen Kostenvoranschlag abzugeben. Wie Sie das machen, bleibt Ihnen überlassen.
Die häufigste Technik, auf die ich stoße, ist die Schätzung von Product Backlog-Elementen in Story Points und Aufgaben in Stunden.
Nein, Scrum erfordert keine Stunden auf Story-Ebene. Tatsächlich würde dies als ein Antimuster angesehen werden. Wenn Sie Stunden verwenden möchten, gelten sie nur auf Aufgabenebene, wo Aufgaben als die „Schritte“ betrachtet werden, die erforderlich sind, um eine Story abzuschließen, basierend auf der Definition of Done Ihres Teams.
Mein Rat ist, Aufgaben und Stunden insgesamt zu überspringen. Stunden werden oft von Einzelpersonen geschätzt und unterliegen einer Vielzahl von Unsicherheiten. Story Points (oder nur Punkte) werden vom Team geschätzt und im Laufe der Zeit verfeinert und verbessert, wenn das Team beim Schätzen besser wird.
Wie @Péter Török bereits erklärt hat, verwendet Scrum Punkte, um User Stories zu schätzen.
Es gibt verschiedene Schätztechniken (Fibonacci, Planungspoker , Zweierpotenzen usw.) und sie beziehen sich darauf, wie wichtig, umfangreich und komplex die Geschichte ist. Zusammen ergeben all diese Punkte die Geschwindigkeit des Sprints (wie viel Arbeit das Team in zukünftigen Sprints leisten kann).
Es wird empfohlen, dass Entwickler diejenigen sind, die jede Geschichte schätzen, da sie am besten wissen, wie viel Aufwand und Zeit sie in Anspruch nehmen werden.