Avis et détails du produit SP Estimating

Dans notre projet actuel, nous sommes 6 développeurs et faisons une estimation basée sur le temps absolu, c'est-à-dire que 2 SP correspondent à un jour et la durée du Sprint est de 4 semaines (20 jours ouvrables). Nous prévoyons donc environ 200 SP (selon le calcul 240 = 2*20*6) avec 40 SP en réserve. Mais nous remarquons depuis les deux derniers Sprints que nous sommes capables de terminer environ 160 SP et maintenant le propriétaire du produit veut connaître la raison de la diminution de la production pour les derniers Sprints car il est clair que même avec la réserve, nous devrions être capables d'atteindre un minimum ou environ 200 SP.

Deuxièmement, je prévois de passer à une estimation relative en utilisant la série de Fibonacci. Mais ma question serait comment prendre une histoire de référence, c'est-à-dire mon histoire utilisateur de 1 ou 2 SP pour l'estimation relative ? Je crois qu'ici encore l'histoire utilisateur de référence devra être estimée en utilisant le temps, c'est-à-dire dire que cette histoire utilisateur nous prend 2 jours et ensuite estimer les autres de manière relative.

Troisièmement et enfin, nous avons la structure suivante pour la formulation des tickets :

Histoire utilisateur, c'est-à-dire ticket de fonctionnalité

- Sous-tâche 1

- Sous-tâche 2

Actuellement, avec l'estimation du temps absolu, nous estimons les sous-tâches et additionnons les SP et mettons à jour le ticket de l'histoire utilisateur principale avec la somme. Est-ce une bonne option ou y a-t-il de meilleures façons et aussi si je passe à l'estimation relative comment devrais-je effectuer l'estimation pour la structure de ticket ci-dessus. Avis collecté par et hébergé sur G2.com.

Erreurs manuelles et consommations de temps. Cela aide l'estimation SP à fonctionner sans problème grâce à l'automatisation. Avis collecté par et hébergé sur G2.com.

Seulement pour essayer de facturer le projet et la justification Avis collecté par et hébergé sur G2.com.