Chiffrages, estimations et autres techniques périlleuses

Hello !!

un petit article pour donner quelques billes pour l’estimation et la construction d’un plan de release, en mode « Scoummm », vu que cette fameuse « non méthode » n’en parle pas 🙂

Postulat :

Nous avons des features, et éventuellement un premier backlog …

Le cas d’aujourd’hui 32 features, dont 12 MUST TO HAVE, 12 SHOULD HAVE et disons 8 NICE TO HAVE

300 US rédigée avec en tant que en deux phrases c’est tt 🙂

Question :

Comment pouvons nous faire pour poser  un plan de départ en disant voilà la première release, avec deux ou trois sprints … sortira plus au moins à telle date ( ajustable et révisable  ) ?

Réponse possible :

  • Estimer la complexité des Features par les développeurs et expliqués par les POs
  • Prendre une Feature moyenne et comparer
  • Pour notre cas, vu qu’il y a 300 PIBs, donc multiplication X 10 de la complexité des features pour avoir celle du projet
  • Donner une vélocité théorique pour le Sprint 1 et répartir le reste sur les Sprints prochains et voir où s’arrête les MUST HAVE ==> Voilà première release avec une date estimée NON GRAVEE DANS LE MARBRE

 

Publicités

Hello,

Une vidéo intéressante, communiquée par l’un de mes stagiaires lors de la formation PO que j’ai donnée le 18 et le 19.

Une bonne vision de la démarche agile globale en quelques minutes 🙂

Réfléchissez à deux fois avant d’intégrer des électrons libres, mêmes performants et efficaces dans vos équipes agiles…

Trop de compétences individuelles tuent les compétences de groupe ? ou au contraire, les font grandir ? Si oui, dans quel cas, sinon pourquoi ???

Up to u !!