Wie schätzen und Geschichte Punkte in Scrum messen? [geschlossen]

Question

Werfen wir ein Beispiel nehmen wir bekamen 5 Geschichten A, B und C, D, E.

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

Die Geschichten werden auf der Grundlage ihrer Bedeutung (Priorität) bestellt. Wie Sie sie schätzen? Ist es auf der Grundlage der Größe des Merkmals geschätzt? Zum Beispiel habe ich ihr Schätzwert gegeben:

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

Nehmen wir an, es ist ein 2-Wochen-Sprint. Dies ist 14 Tage Zeit size = 5,14x5 = 70 Manntage. Was bedeutet nun der Wert 10 bedeutet? Bedeutet es, viel Zeit (Stunden oder Tage) ein Team sollte verbringen? Und was sind Geschichte Punkte? Angenommen, dies ist der erste Sprint ist; Wie werden Sie die Anzahl der Sprints schätzen, wenn Sie nicht den letzten Sprint der Geschwindigkeit haben?

Answer 1

Argh! Geschieht mir recht für aus dem Speicher zu schreiben.

Eine Geschichte Punkt der Schätzung natürlich im Zusammenhang, und wenn Sie versuchen, herauszufinden, wie viel Sie für einen Sprint tun, eine Geschichte Punkt ist eine Einheit der „Arbeit“ benötigte Teil oder eine ganze Funktion zu implementieren. Eine Geschichte Punkt könnte ein Tag oder eine Stunde oder etwas dazwischen. Ich habe unter den „schätzen“ und „Geschichte Punkt“ verwirrt, weiß nicht, was ich dachte.

Was ich ursprünglich geschrieben war „schätzt“ und „Story-Punkte“. Was ich meinte (und redigiert unten) zu schreiben, war „Geschichte Punkte“ und „Geschwindigkeit“.

---

Geschichte Punkte und Geschwindigkeit geht Hand in Hand, und sie arbeiten zusammen, um zu versuchen, um Ihnen ein Gefühl von „Wie viel können wir in einer bestimmten Zeit beenden“.

Lassen Sie uns ein Beispiel nehmen.

Angenommen, Sie Merkmale in Stunden abschätzen wollen, so eine Funktion, die eine Schätzung von 4 hat, wird 4 Stunden in Anspruch nehmen, von einer Person, so dass Sie auf alle Funktionen einer solchen Schätzung zuweisen. Sie halten also diese Funktion, oder seine „Geschichte“, im Wert von 4 Punkten, wenn es um im Wettbewerb um Ressourcen geht.

Nun wollen wir auch sagen, Sie haben 4 Personen auf dem Projekt, die jeweils eine normale 40-Stunden-Woche zu arbeiten, aber wegen anderer Dinge um sie herum geschieht, wie Unterstützung, im Gespräch mit Marketing, Tagungen, usw., wird jede Person nur die Lage sein, 75% auf den tatsächlichen Eigenschaften zu arbeiten, wird das andere 25% auf den anderen Aufgaben verwendet werden.

So hat jede Person 30 Stunden zur Verfügung jede Woche, die Sie 30 * 4 = 120 Stunden insgesamt für diese Woche gibt, wenn Sie alle 4 Personen zählen.

Nun wollen wir auch sagen, dass Sie versuchen, einen Sprint von 3 Wochen zu schaffen, das heißt, Sie haben 3 * 120 Stunden Arbeit wert Sie abschließen können. Das ist Ihre Geschwindigkeit, wie schnell Sie sich bewegen, wie viele „Story Points“ können abzuschließen.

Das Gerät Ihrer Geschwindigkeit muss er mit der Einheit für Ihre Story Points kompatibel. Sie können keine Geschichten messen „wie viele Tassen wird der Entwickler (n) verbrauchen, während dieser Umsetzung“ mit „wie viele Stunden haben wir zur Verfügung“.

Sie dann versuchen, eine Reihe von Funktionen zu finden, die nimmt nahe beieinander, aber nicht über 120 Punkte, rangieren nach ihrer Priorität. Dies würde einfach sein, von oben akkumulativen zusammenzufassen und nach unten, bis Sie eine Aufgabe, die Tipps der Summe über oder gleich, jene 120 Punkte erreichen. Wenn es sie umkippte, enthalten nicht die Aufgabe.

Sie könnten genauso gut in Tagen schätzen, oder Tassen Kaffee vom Entwickler verbraucht, ebenso wie die Zahl ist repräsentativ für die Art der Arbeit Sie tun, und es kann auf die eigentliche Arbeit in Beziehung gesetzt werden Sie durchführen werden ( dh., wie viel Zeit Sie zur Verfügung haben).

Sie sollten auch Ihre Arbeitsbelastung bewerten nach jedem Sprint, um herauszufinden, ob die 75% Zahl korrekt ist. Zum Beispiel, wenn Sie nur die Hälfte geschafft, was Sie sich vorgenommen haben, herauszufinden, ob die Feature-Schätzungen falsch war, oder wenn Ihre Arbeitsbelastung Schätzungen falsch war. Dann nehmen Sie, was Sie berücksichtigen gelernt haben, bei der Schätzung und Planung für den folgenden Sprint.

Beachten Sie auch, dass Merkmale aufgeteilt werden sollten, wenn sie zu groß geworden. Der Hauptgrund dafür ist, dass größere Schätzungen viel mehr Unsicherheit in sie aufgebaut haben, und Sie können, dass mildern, indem es nach oben in Unterfunktionen aufgeteilt und diejenigen zu schätzen. Das große Gesamtmerkmal wird dann die Summe aller Unterfunktionen. Es könnte Ihnen auch die Möglichkeit geben, die Funktion über mehrere Personen aufgeteilt, die von verschiedenen Unterfunktionen an verschiedene Personen zugeordnet werden.

Eine gute Faustregel ist, dass Funktionen, die eine Schätzung über 1 Tag haben sollten wohl aufgeteilt werden. *

Answer 2

Beachten Sie, dass Punkte nur ROMs (grobe Größenordnung) durch die Verwendung etabliert sind „ Planning Poker “als gängige Praxis. Die ersten paar Sprints sind, wenn Sie zu identifizieren beginnen, was die Punkte für das Team bedeuten und je länger Sie gehen desto genauer wird das Team bekommt.

Plus schauen Punkte zu verwenden, die ein bisschen mehr gestaffelt sind. Eine Praxis, die ich gesehen habe und verwendet, um die Fibonacci Sequenz zu verwenden, ist es sicher, dass Sie don ‚t haben zu viele 1 Punkt Unterschiede.

Auch Tester nicht vergessen, wenn eine Geschichte jemand zeigen Tests tun muss in wie manchmal eine einfachen Entwicklungsaufgabe wiegen kann einen großen Testaufwand verursachen und wenn sie die Idee wahr Sprinte sind, ist alles fertig zu haben, wie es sein könnte ausgeliefert (gebaut, geprüft und dokumentiert). So ist die Schätzung einer Geschichte, die das Team nicht von einem einzelnen bestimmt wird.

Answer 3

Der Wert 10 ist lediglich ein Wert im Verhältnis zu den anderen Schätzungen, z.B. es ist halb so schwer wie ein 20 oder etwas schwieriger als ein 9. Es gibt keine spezifische Übersetzung von 1 Punkt = x Stunden Aufwand ist etwas hinweisen.

Wo ich arbeite, haben wir das, was wir „epic Punkte“ nennen, die, wie schwer es einige hohe Geschichte ist, z. Suchen Sie in eine neue Webseite integrieren, die aus mehreren Geschichten bestehen zu vervollständigen und dann schätzen wir Stunden auf jeder Geschichte, die aus bricht jedes Epos geschaffen, z. Suchen Sie in setzen nur für Support-Dokumente auf der Website. Die „epic Punkte“ in einer Variation der Fibonacci-Zahlen verteilt (1,2,3,5,8,13,21,28,35), so dass breiterer, vageer Epen nur einen großen Wert erhalten, z.B. etwas größer als 8, ist ein Indikator, dass es nach unten in leichten abschätzbare Geschichten gebrochen werden kann. Es ist auch erwähnenswert, hier, dass, wo ich arbeite wir nur 5 Tage pro Woche arbeiten und innerhalb jedem schon am Tag Treffen wie die Demo verloren, Iterationsplanung Treffen, retrospektive und Überprüfung, so gibt es nur noch 9 Tage bis zu einem Sprint ist. Hinzufügen in Paarprogrammierung für einige Dinge, die Zeit für Bugs und andere Nicht-Projektarbeit wie Support-Tickets Festsetzung und es wird ziemlich schwer zu sagen, wie viele Stunden wird von der Handvoll Entwickler im Sprint ausgegeben werden.

Die ersten paar Sprints sind, wo die Werte beginnen konkreter zu werden, wie auf der Grundlage der gewonnenen Erfahrungen können die Schätzungen klarer werden, in Bezug darauf, wie der Wert zu erraten.

Answer 4

Mit einem neuen Team oder Projekt, das wir beginnen immer durch eine Geschichte Punkt unter der Annahme ist ein einziger „idealer Tag“, und wir Figur jeden Entwicklers immer rund 3,5 ideal Tage pro Woche, das ist, wie wir unsere wahrscheinlich Anfangsgeschwindigkeit berechnen.

Sobald Sie durch die „Planung Poker“ Bühne und ausgewogen / verglichen alle Ihre Geschichten gegangen sind, die tatsächliche reale Dauer einer Geschichte Punkt ist wirklich unbekannt - alles, was Sie wirklich haben, ist eine ziemlich gute Vorstellung von relativ Dauer, und verwenden Sie am besten Urteil mit einer wahrscheinlichen Geschwindigkeit zu kommen.

Zumindest das ist, wie ich es tun!

Wenn Sie werden auch Ihre Geschichte Punkte darauf abzielen, etwa gleich einen idealen Tag zu sein, dann würde ich vorschlagen, Ihre Geschichten in kleinere Geschichten zu brechen, sonst sind Sie nicht eine gute Zeit bei der Planung und Tracking-Iterationen haben gehen.

Answer 5

Gute Antworten überall.

Ein Punkt Ich mag würde hinzufügen, dass es nicht wirklich wichtig ist, was Sie als Basis für Ihre Punkte Wert wählen (Stunden, ideal Tage, was auch immer). Das wichtige ist es konsistent zu halten.

Wenn Sie es konsistent halten es erlaubt Ihnen, „wahre Geschwindigkeit“ Ihres Teams zu entdecken. Zum Beispiel können Sie sagen wenige Iterationen hatte:

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

Und jetzt beginnen Sie Iteration 4 und Sie haben die folgende in dem Rückstand (nach Priorität geordnet):

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

Es wird nun angenommen Ihre Punkte Schätzungen konsistent sind, können Sie ziemlich sicher sein, dass das Team Artikel 1,2 und wahrscheinlich 3 fertig werden, aber auf keinen Fall 4.

Sie können das gleiche gilt Rückstand zu lösen Ihre Vorhersage der Veröffentlichungstermin zu verbessern. Dies ist, was Scrum-Teams ermöglicht, ihre Schätzungen zu verbessern, wie sie mitgehen.

Answer 6

JB König hat die beste Antwort, aber keine Stimmen, die falsche Informationen bedeutet, wird auf die allgemein schlechte Interpretation von gedränge propagiert und einen Beitrag. Bitte beachten Sie die echten Antworten von einem der Menschen, die Scrum hier entworfen:

http: //blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Denken Sie daran, es geht um Mühe, nicht die Komplexität.

Nun lesen und ein Video hier:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points