Elément du backlog de produit, le modèle

A l'occasion d'évolutions dans IceScrum, j'ai remis à jour le (méta) modèle de l'élément de backlog de produit.

Le backlog de produit contient des éléments. Un élément de backlog est généralement qualifié de story.

Mais ce n'est pas si simple. A partir des idées de ce billet, j'ai modélisé la typologie qu'on retrouve dans Icescrum :



Modèle d'un élément du backlog de produit

  • Un élément peut aussi être une feature, avant sa décomposition en stories.
  • Une user story correspond à un type de story qui apporte de la valeur directe aux utilisateurs.
  • Un défaut est une story qui enlève de la valeur s'il n'est pas corrigé.
  • Une story technique est une story qui n'apporte pas de valeur directe aux utilisateurs. Cela inclut les spikes (des études) et les travaux d'architecture, d'infrastructure ou d'outillage de l'environnement de développement.

Pendant un sprint, une story est réalisée en accomplissant un certain nombre de tâches.

Une story est définie par ses tests d'acceptation, qui permettront de vérifier qu'elle est finie à la fin du sprint.

Commentaires

1. Le mardi 20 janvier 2009, 10:50 par Pascal

Ah, le joli métamodèle UML ! Tu me fais chaud au coeur, Claude :-)

Bon, pour faire avancer le schilimili..., une question : est-ce qu'une technical story est vraiment une story ? Peut-elle être rattachée à une feature ? N'est-ce pas plutôt transverse ?

ce qui peut être qualifié de transverse, ce serait une exigence non fonctionnelle. Une technical story peut être attachée à une feature, elle répond aussi aux caractéristiques habituelles d'une story : estimable, testable, qu'on peut finir en une itération...
2. Le mardi 20 janvier 2009, 12:26 par Matthieu

Un backlog produit ne contient donc pas seulement des éléments qui apportent de la valeur ajouté au produit (defaut, archi, ...).
Ton schéma est vraiment bien. On comprend très vite.
Merci