SP Estimating Bewertungen & Produktdetails

In unserem aktuellen Projekt sind wir 6 Entwickler und machen absolute zeitbasierte Schätzungen, d.h. 2 SP entsprechen einem Tag und die Sprint-Dauer beträgt 4 Wochen (20 Arbeitstage). Also planen wir ca. 200 SPs (laut Berechnung 240 = 2*20*6) mit 40 SP als Puffer. Aber wir bemerken seit den letzten zwei Sprints, dass wir ungefähr 160 SPs schaffen, und jetzt möchte der Product Owner den Grund für den Rückgang der Leistung in den letzten Sprints wissen, da klar ist, dass wir selbst mit Puffer mindestens oder ungefähr 200 SPs erreichen sollten.

Zweitens plane ich, zu relativen Schätzungen mit der Fibonacci-Reihe überzugehen. Aber meine Frage wäre, wie man eine Referenz-Story nimmt, d.h. meine 1 oder 2 SP User Story für die relative Schätzung? Ich glaube, dass hier wieder die Referenz-User-Story zeitlich geschätzt werden muss, d.h. sagen wir, diese User Story benötigt 2 Tage und daraufhin andere relativ schätzen.

Drittens und letztens haben wir die folgende Struktur für die Ticket-Formulierung:

User Story, d.h. Feature-Ticket

- Unteraufgabe 1

- Unteraufgabe 2

Derzeit schätzen wir mit absoluter Zeitschätzung die Unteraufgaben und summieren die SPs und aktualisieren das Haupt-User-Story-Ticket mit der Summe. Ist das eine gute Option oder gibt es bessere Wege und auch, wenn ich zu relativen Schätzungen übergehe, wie sollte ich die Schätzung für die obige Ticketstruktur durchführen? Bewertung gesammelt von und auf G2.com gehostet.

Manuelle Fehler und Zeitaufwand. Es hilft der SP-Schätzung, reibungslos durch die Automatisierung zu arbeiten. Bewertung gesammelt von und auf G2.com gehostet.

Nur für den Versuch, das Projekt abzurechnen und die Begründung. Bewertung gesammelt von und auf G2.com gehostet.