Wir fangen gerade mit Scrum an und hatten einige Debatten darüber, ob wir in Story Points oder in idealen Stunden schätzen sollten. Das Team ist ziemlich gespalten, daher würde ich gerne wissen, ob echte Studien darüber durchgeführt wurden, was effektiver ist. Ich habe sicherlich viele Meinungen darüber gelesen, was besser ist, und obwohl es für jede gute Argumente gibt, habe ich kein einziges Buch, keinen Artikel oder Post auf einer Webseite gefunden, das durch konkrete Zahlen gestützt wird.
Also, gab es Studien, die mir nicht aufgefallen sind? Wie wäre es mit psychologischer Forschung zu absoluten vs. relativen Schätzungen? Wenn diese nicht vorhanden sind, was ist mit realen Beispielen dafür, was für verschiedene Teams in verschiedenen Arten von Unternehmen funktioniert hat?
Mike Cohn in Agile Estimating and Planning beschreibt die Schätzung anhand von Story Points und idealen Tagen in den Kapiteln 4-5 und vergleicht sie dann in Kapitel 8. Zur Forschung:
Es gibt glaubwürdige Beweise dafür, dass wir „das ist so“ besser einschätzen können als die absolute Größe von Dingen (Lederer 1998; Vicinanza 1991).
Die Quellen dieser Zitate sind angegeben als
Im Allgemeinen sind ideale Tage für einige Personen/Teams möglicherweise leichter nachzuvollziehen, es besteht jedoch die Gefahr, dass sie zu leicht (auch unbewusst) als konkrete Tage ( verstrichene Zeit ) interpretiert werden, die dann möglicherweise sogar als Verpflichtung angesehen werden (durch z Verwaltung). Dies ist hauptsächlich der Grund, warum viele Story Points verwenden, um jede Möglichkeit einer Fehlinterpretation zu vermeiden. Bei Story Points ist immer klar, dass wir die relative Größe schätzen, nicht die Dauer.
Es kann auch wichtig sein zu beachten, dass Story Points nicht direkt in effektive Arbeitsstunden / -tage übersetzt werden können; Über einen längeren Zeitraum kann ein Team natürlich berechnen, wie viel Zeit ein Story Point im Durchschnitt benötigt ; Dies bedeutet jedoch nicht, dass Sie diesen Wert verwenden können, um die Zeit zu berechnen, die zum Abschließen eines bestimmten Elements erforderlich ist. Im wirklichen Leben kann sich herausstellen, dass ein konkretes Element mit 2 Story Points genauso viel Zeit zur Fertigstellung benötigt wie ein anderes Element mit 1 Story Point – oder es kann dreimal so viel Zeit erfordern. In einer größeren Stichprobe gleichen sich diese individuellen Schwankungen jedoch tendenziell gut aus, sodass Story Points verwendet werden können, um die Team-Velocity langfristig abzuschätzen.
Mike selbst bevorzugt eindeutig Story Points:
Ich bevorzuge Story Points. Ich finde die Vorteile, die sie als reines Größenmaß bieten, überzeugend. Dass Story Points dazu beitragen, funktionsübergreifendes Teamverhalten zu fördern, ist ein großer Vorteil. Die Denkweise eines Teams von „mein Teil dauert drei ideale Tage und Ihr Teil dauert zwei ideale Tage, also insgesamt fünf ideale Tage“ zu ändern, unterscheidet sich sehr von „insgesamt scheint diese Geschichte ungefähr die gleiche Größe wie diese zu haben, also nennen wir sie fünf Story Points auch.“ Dass ein Story Point für mich dasselbe sein kann wie ein Story Point für Sie, während dies möglicherweise nicht für einen idealen Tag gilt, ist ein weiterer großer Vorteil. Zwei Entwickler mit unterschiedlichen Fähigkeiten oder Erfahrungen können sich über die Größe von etwas einigen, während sie sich nicht darüber einig sind, wie lange es dauern wird.
Die Mängel der Story Points sind in der Tat kurz. Ja, es ist einfacher, mit idealen Tagen anzufangen. Das Unbehagen, mit nebulösen Story Points zu arbeiten, ist jedoch nur von kurzer Dauer. Ideale Tage sind definitiv einfacher für diejenigen außerhalb des Teams zu erklären, aber wir sollten wahrscheinlich nicht danach wählen, wie schwer es sein wird, Außenstehenden zu erklären. Dass ideale Tage so leicht nachvollziehbar sind, bereitet ebenfalls Probleme. In einigen Organisationen wird es Druck geben, einen tatsächlichen Tag einem idealen Tag näher zu bringen. Druck für mehr Fokus und Konzentration auf unsere Arbeit ist in Ordnung. Aber der organisatorische Druck, dass jeder tatsächliche Tag einem idealen Tag nahe kommt, wird auch dazu führen, dass wir die tatsächliche Zeit schätzen, während wir ihn als idealen Tag bezeichnen. Das heißt, ein idealer Tag wird neu definiert als „ein Tag, an dem ich sechs Stunden Fortschritte mache und zwei Stunden lang andere Dinge erledige“.
Ich bin gerade auf einen weiteren Artikel aus dem Blog von Jeff Sutherland mit Forschungsdetails und Links gestoßen:
Schauen Sie sich diesen Blogbeitrag von Jeff Sutherland zu Story Points an: Warum sind sie besser als Stunden?
Dies wird von ihm in der Diskussion unterhalb des Blogs weiter energisch verteidigt.
In diesem Blogbeitrag nennt er die folgenden Beispiele. Diese können Ihnen als „Beispiele aus der Praxis dafür, was für verschiedene Teams in verschiedenen Arten von Unternehmen funktioniert hat“ hilfreich sein:
Eine Studie von 80 Multimillionen-Dollar-Projekten bei GSI Commerce (jetzt im Besitz von eBay) hat gezeigt, dass die besten Experten im Unternehmen völlig unfähig waren, abzuschätzen, wie viel Zeit ein Projekt von den Leuten, die es tatsächlich umsetzen würden, in Anspruch nehmen würde.
Forschungen der Rand Corporation in den 1940er Jahren zeigten deutlich, dass Menschen nicht gut darin sind, Stunden zu schätzen, und praktische Erfahrungen bestätigen wiederholt diese Forschung. Der empfohlene Delphi-Ansatz zur Schätzung, der in der Softwareentwicklung als Breitband-Delphi-Technik übernommen wurde. Die gleiche Technik ist jetzt in die Praxis namens Planning Poker für agile Teams eingebettet.
Ein CMMI-Level-5-Unternehmen stellte fest, dass die Story-Point-Schätzung die Schätzzeit um 80 % verkürzt, sodass Teams mehr Schätzen und Nachverfolgen durchführen können als ein typisches Wasserfall-Team.
Ein Telekommunikationsunternehmen bemerkte, dass geschätzte Story Points mit Planungspoker 48-mal schneller waren als Wasserfallschätzungspraktiken im Unternehmen, und gab ebenso gute oder bessere Schätzungen ab.
Eine klassische Erklärung zu Story Points – ein Maß für Aufwand (Zeit). Dieser Artikel ist 4 Jahre alt und wir arbeiten seit fast 20 Jahren agil, aber immer noch missverstehen die Leute Story Points. Ich habe oft Story Points gehört, die auf Aufwand oder Komplexität basieren. Es geht aber immer um den Aufwand und die Komplexität beeinflusst den Aufwand. Ich glaube, das Beispiel in diesem Artikel wird diese Debatte (Missverständnis) beenden: https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort
Bei Story Point geht es um Schätzungen, aber was für mich 2 Tage dauern könnte, könnte für eine andere Person 1 Tag dauern. Also vereinbaren wir als gemeinsame Einheit 1 Punkt. So kann ich in einem 10-Tage-Sprint 5 Punkte schaffen und die andere Person 10 Punkte. Irgendwann werde ich erfahrener und mache mehr Punkte.
Andreas klar