Eléments du backlog : Features, stories et spikes revisités

Que met-on dans le backlog ? L'an dernier, j'avais fait un billet sur les features, stories, epics....

Aujourd'hui je revisite ces notions à l'occasion d'évolutions dans IceScrum, qui les embarque actuellement de façon pas très limpide. Pour simplifier l'usage, nous allons fusionner les notions de thèmes et de features, et nous appuyer sur des idées de Dean Leffingwell et Philippe Kruchten.

Le backlog de produit contient des éléments, qui sont :

  • soit visibles des utilisateurs et apportant de la valeur comme les user stories,
  • soit visibles et enlevant de la valeur comme les défauts (les bugs),
  • soit invisibles des utilisateurs et donc sans valeur apparente, mais demandant quand même du travail, comme par exemple les spikes ou des travaux d'architecture.

Une feature est une fonctionnalité essentielle. Une feature se décompose en éléments de backlog.

Les features servent -notamment- à amorcer le backlog. La démarche pour un nouveau projet est de :

  • identifier les features pour en obtenir de 5 à 12 et en les consolidant de façon à constituer des domaines fonctionnels indépendants. Les features seront décomposées, au moment où ce sera nécessaire, en stories.
  • décider des priorités entre les features, par une session de priority poker ou un autre moyen.
  • pour les 1 ou 2 features les plus prioritaires, décomposer en stories détaillées (normales), en pratiquant par exemple un story workshop. Les stories, associées à leur feature, sont placées dans le backlog.

Dans la version d'IceScrum qui va sortir mi-décembre, un élément du backlog possèdera :

  • un nom court
  • un rang dans le backlog, correspondant à sa priorité relative
  • une description détaillée (de la forme "en tant que..." si c'est une story)
  • une estimation de coût
  • l'estimation de la valeur est au niveau de la feature
  • des cas de tests associés
  • la trace de la feature dont elle est issue
  • une idée de sa fréquence d'exécution (une story peut se dérouler selon le cas plusieurs fois par jour ou une fois par semaine)
  • un rôle associé (l'utilisateur qui est à l'initiative de la story)
  • et pour la gestion de projet, un état, le sprint dans lequel il est planifié et les tâches permettant de le réaliser.

Commentaires

1. Le mercredi 03 décembre 2008, 13:52 par dprince

Quid des items soulevés lors de la retrospective: actions visant a améliorer la vélocity de l'equipe: serveur de build,...?
Tu les mets egalement dans le Backlog a l'issu de la reunion?


Claude : Oui, pour du travail technique à faire par l'équipe et visant à mettre en place un serveur build, je le mettrais dans le backlog de produit, avec le type "invisible des utilisateurs".