gérer son Product Backlog

Capture d'écran 2014-08-03 23.04.05

Le Product Backlog comme le Sprint backlog décroissent jusqu’à atteindre le point de permutation entre Releases.

Avoir un Backlog constamment maintenu à son maximum est contre productif dans une gestion pérenne: un Product Backlog pour un produit cela ne signifie pas une collection de produits (portefeuille).

La force de la gestion de backlog dégressive repose sur la notion cognitive de « pouvoir de l’achèvement »: finir dynamise et motive les équipes.

Comme représenté sur le graphique, la vélocité représente le montrant de backlog consommé pendant un sprint. Ce montant permet d’estimer en combien d’itérations vous livrez.

En fin de Sprint, les participants au projet repriorisent le backlog, et les éléments reportés constituent le product backlog de la prochaine release.

Les 10 principales erreurs de gestion du Product Backlog:

  1. product owner impose à l’équipe de suivre la priorisation business dans le Sprint
  2. pas de priorisation en fonction de la business value
  3. le Product Backlog est un puits sans fin se remplissant à la même hauteur pendant et à la fin du Sprint
  4. les stories ne sont pas claires et pas testables
  5. le Product Owner sous la pression du management utilise le Product Backlog pour pousser/forcer l’équipe de développement (NB un Sprint Backlog fonctionne uniquement en flux tiré)
  6. une story bloquant la progression de la consommation n’est pas sortie du Product Backlog
  7. la Product Backlog est utilisé comme liste de tâches
  8. les équipes n’arrivant pas à gérer un simple Product Backlog passent en mode Feature Team sans penser à la gestion des nouveaux Product Backlog (approche Programme) en pensant que cela va solutionner leur problème qui va de bien entendu empirer.
  9. les Product Owners n’ont jamais suivi de formation et ne savent ce qu’est un Product Backlog
  10. créer un Product Backlog sans vision du produit

 

télécharger le document sur la gestion de Product Backlog ici