Jira-Story-Punkte im Vergleich zur Schätzung von Unteraufgaben

Der Grund, warum Scrum-Teams häufig Story Points zum Schätzen verwenden, ist, dass sie eine effektive Möglichkeit bieten, die Kapazität eines Teams zu berechnen. Sie ermöglichen auch eine einfache Prognose bei der Release-Planung.

Die Gründe, warum sie zeitbasierte Schätzungen für Aufgaben verwenden, sind unterschiedlich. So können sie:

• Verbringen Sie Zeit damit, die Arbeit aufzuschlüsseln, was oft bei der Implementierung hilfreich ist
• Kann überprüfen, ob sie sich in einem Sprint nicht zu sehr verpflichtet haben (es mag als Story Points gut ausgesehen haben, aber die Aufgabenaufschlüsselung kann eine zu hohe Verpflichtung aufdecken)
• Stellen Sie sicher, dass sie eine bestimmte Disziplin nicht überlastet haben (z. B. zu viel Testarbeit und das Team setzt dedizierte Tester ein).

Viele Scrum-Teams beginnen mit diesem Ansatz, da er hilft, einige der Fallstricke eines Teams zu vermeiden, das neu bei Scrum ist. Erfahrenere Teams können die zeitbasierten Schätzungen fallen lassen, wenn sie sie nicht mehr für wertvoll halten.

+1000 auf Daniels Post: Verwenden Sie überhaupt keine Arbeitsstunden.

Stundenschätzungen werden von vielen führenden Agile-Experten empfohlen. Und dann schauen, dass die Zeitstempel. Mir ist keine führende agile Stimme bekannt, die noch die Stundenerfassung von Aufgaben unterstützt. Es wurde als kontraproduktiv für die relativistische Schätzung von Story Points angesehen. Das Ziel der Schätzung besteht nicht darin, herauszufinden, wie viele Stunden es dauern wird, es ist ausschließlich Sache des Teams, zu entscheiden, wie viel Arbeit es im Sprint übernehmen kann.

Es ist uns egal, wie lange eine Aufgabe oder sogar eine Geschichte dauert. Es ist uns wichtig, ob das Team das liefert, was es erwartet hat.

Anstelle von Stunden für Aufgaben lautet die allgemeine Richtlinie, nach der ich Teams coache: „Aufgaben sollten in die Arbeit eines Tages passen.“ Dies ermöglicht eine einfachere Verfolgung des Status, da Sie von täglichem Aufstehen zu täglichem Aufstehen Aufgaben erledigen sollten. Dies ist eine ALLGEMEINE Richtlinie. Denken Sie auch daran, dass ein "Tag" wirklich nur 4-5 Stunden tatsächlicher Arbeit ist.

Machen Sie einfach Story Points! Wenn Sie bereits Informationen über Ihre Geschwindigkeit erhalten haben, müssen Sie die Stunden nicht zusätzlich schätzen. Normalerweise schätzen wir nur die Komplexität der Geschichte und in der Planung bekommt das Team die Möglichkeit, die Geschichte nach der Planung aller Aufgaben neu zu schätzen. Das Team verpflichtet dann nur die Geschichten, die es im Sprint schafft.

-- Bearbeiten

Unser Team besteht auch aus Backend (Java) und Frontend (HTML, CSS, ... ). Wie in Ihrer Beschreibung haben die Geschichten immer unterschiedliche Beziehungen beider Fähigkeiten. Normalerweise beginnt der Product Owner, die Geschichten zu präsentieren, beginnend mit den wichtigsten. Nach jeder präsentierten Geschichte fragen wir das Team, ob sie mehr tun können oder ob wir hier aufhören sollen. Wenn eine der Fähigkeitsgruppen genug für den Sprint hat, gehen wir den Rückstand von oben nach unten durch und nehmen die nächste Geschichte, die die anderen erledigen können. Ich hoffe es hilft!

Im Fall Ihres Teams würde ich sagen, dass eine Änderung Ihres Schätzungsprozesses angebracht ist. Da Sie zu dem Schluss gekommen sind, dass es Ihnen schwer fällt, eine genaue Schätzung vorzunehmen, bis Sie alle Aufgaben kennen, die erforderlich sind, um die Geschichte zu erfüllen, sollten Sie sich diese überlegen, bevor Sie Ihre Schätzung vornehmen.

Sie können dies während Ihres normalen Sprint-Planungsprozesses tun, einfach die zu diskutierende Geschichte so vollständig wie möglich beschreiben, vielleicht eine kurze Debatte darüber führen, was der beste Ansatz zur Lösung dieses Problems ist, und dann einfach alle Aufgaben aufschreiben (vorzugsweise auf Post- damit Sie sie später nicht erneut aufschreiben müssen) und stützen Sie Ihre Schätzungen auf den Gesamtaufwand für diese Aufgaben + angemessene Tests.

Selbst bei diesem Ansatz sollte Ihr Team immer noch eine bestimmte Anzahl von Punkten haben, bei der die Story in mehrere Storys aufgeteilt wird, wenn die Schätzung höher ist als diese Menge. Versuchen Sie immer, Ihre Geschichten so in sich geschlossen wie möglich zu halten und sie dennoch in einem einzigen Sprint leicht erreichbar zu halten.

Es klingt für mich so, als ob es Ihre Teamorganisation ist, die die Wurzel Ihres Problems ist.

Wenn Sie wissen müssen, wie viel SQL-Arbeit es in Sprint gibt, nehme ich an, weil der SQL-Typ Däumchen dreht, wenn es nicht viel gibt, und es scheint, als könnten Sie noch ein paar SQL-Aufgaben hineinquetschen.

Das Problem dabei ist jedoch, dass es die Fertigstellung von Geschichten durcheinander bringt. Es ist sehr schwierig zu sagen, dass eine einzelne Aufgabe erledigt ist, es sei denn, man kann auch sagen, dass die Geschichte erledigt ist.

ZB habe ich eine Aufgabe: Db für Webseite schreiben und Aufgabe: HTML für Webseite schreiben.

und Feature: Webseite zeigt den Benutzernamen.

Wenn sie nicht als Team zusammenarbeiten, könnten sowohl die HTML- als auch die SQL-Aufgaben als erledigt markiert werden, wobei jeder Programmierer davon ausgeht, dass die andere Aufgabe die Benutzernamenfunktion ausführt.

Wenn Sie am Ende ankommen und das Feature noch nicht fertig ist, aber der SQL-Typ mit einer anderen Aufgabe für eine andere Geschichte beschäftigt ist und nicht zum Feature zurückkehren kann, haben Sie am Ende viele offene Aufgaben und sind irgendwie fertig ' Merkmale.