Bac d'affinage et plan de release
Plan de release ou pas ?
Dans une situation où il est nécessaire d’avoir un plan à moyen terme -un plan de release- voilà comment se servir du bac d’affinage.
Plan de release, ou pas, c’est la question. Si la réponse est oui, les bacs facilitent grandement son élaboration et son suivi.
Pendant le sprint zéro (ou après), on place dans ce bac tout ce qu’on prévoit de faire pour la date de fin de release. Bien sûr il ne s’agit pas de tout décomposer en stories, donc on se retrouvera aussi avec des epics.
L’objectif devient de vider ce bac d’affinage pour la fin de la release.
On peut estimer en points son contenu, qui représente ce qu’il y a à faire pour la release. On peut tout simplement compter les stories et epics, si on a des données statistiques indiquant, par exemple, qu’en moyenne un epic vaut 3 stories.
Pendant le déroulement des sprints, le bac d’affinage va évoluer :
- des stories prêtes vont passer dans le bac de départ,
- de nouvelles stories vont apparaître, soit par décomposition des epics soit par approvisionnement à partir du bac à sable,
- le Product Owner pourra aussi purger des stories et, surtout en fin de release, déscoper en plaçant les stories repoussées à la prochaine release.
C’est là qu’intervient le bac à glace dans lequel on met tout ce qui n’est pas pour la release courante. Une fois la fin de la release atteinte, le bac d’affinage sera réapprovisionné par injection à partir du bac à glace.
Comme indicateur on utilisera un burndown de release ou mieux un burnup à deux courbes, ou encore mieux un diagramme de bacs empilés, comme ci-dessus.
