Dans votre équipe, comment ordonnez vous vos product et sprint backlogs ? Est-ce que vous utilisez le même ordre pour les deux ? Pourquoi utilisez vous cet ordre (im)précis ? Quels bénéfices et désavantages y voyez-vous ?
Je dois en déduire que personne n’ordonne ses backlogs ?
D’ailleurs ça me fait penser, mais je connais que très peu d’équipes de dev qui réorganisent leur sprint backlog. C’est assez intéressant comme observation… 
Je trie les backlogs items par priorité, y compris au sein des sprints en fonction de l’urgence / la valeur attendue.
Les équipes de dev qui réorganisent leur sprint backlog, j’en ai réellement connu qu’une…
Pour ordonner le product backlog, j’aime beaucoup le story mapping. Ca donne un ordre, et pas juste une prio, visuelle très bien faite et claire (IMO).
Pour le sprint backlog, la fois où je l’ai réellement vu, c’était les devs qui réordonnaient sur un (vrai) kanban leur propre sprint backlog, en enlevant ou rajoutant des tâches pour atteindre leur objectif.
1 « J'aime »
Au niveau du sprint backlog, l’ordre est plutôt organisé par ordre d’implémentation qui est en général lié à la technique.
Côté product backlog, ça va plutôt être un ensemble d’intentions (je sais pas si on peut dire ça) que je gère par Miro pour me donner et donner de la visibilité.
Les intentions seront la base des objectifs de sprints en fait
Chaque ligne regroupe les « enjeux » du produit, chaque colonne les sprints cibles
Les intentions sont positionnées dans une roadmap qui n’a rien de figée, je déplace les intentions très régulièrement suivant les enjeux métiers du moment.
J’indique aussi les dépendances fonctionnelles entre les sujets pour faciliter les perspectives de planification
Derrière chaque intention il y a un ensemble de PBI plus ou moins dégrossis qui seront étudiés en raffinage et choisis en sprint planning (des US, des bugs)
Chaque intention donne du sens à l’équipe (du moins j’espère 
), on essaye d’apporter le max de valeur possible sur cet enjeu en adaptant le contenu du sprint au jour le jour suivant l’avancement. On essaye de se donner de la marge car très souvent en milieu de sprint des idées émergent et on aimerait plutôt partir dans une direction initialement pas prévu et il faut de la souplesse niveau timing.
J’essaye vraiment qu’à chaque sprint l’incrément apporte vraiment quelque chose d’indépendant des futurs incréments ainsi on a vraiment l’impression d’avoir donné le max sur un sujet pendant le sprint et ensuite on peut passer à un autre sujet.
Dans nos équipes où on utilise Scrum, on n’ordonne pas particulièrement le product backlog. Il ne contient que les items de la prochaine version majeure (quelques sprints). « Au dessus » du product backlog on a une story map qui présente un découpage en versions. On essaye donc de limiter la taille du product backlog (20-30 items). Les User Stories en particulier sont associées à des Epics (grosse fonctionnalité). On a cependant une zone (le « prochain » sprint) où on place les prochains items pressentis pour le dev, et donc à affiner/préparer.
On ordonne les items du sprint backlog selon ce qui nous semble faire du sens pour atteindre l’objectif. Ca peut bouger pendant le sprint.
1 « J'aime »
Quand tu dis « priorité », c’est pour qui ? Et avec quels critères pour définir ces priorités ?
Pour ma part au niveau product backlog, l’on, l’équipe, gère principalement les dépendances techniques ou grandes fonctionnalités, ex j’ai besoin d’une api de type store locator pour proposer d’afficher des point sur une carte.
Dans le sprint l’on priorise par valeur au niveau fonctionnalités pour avoir quelque chose de fonctionnel au plus vite et du feedback, ex afficher une liste d’items pour pouvoir les voir puis réaliser une fonction de filtre, puis de recherche ou de tri (si toute fois cela ne fait sens au niveau découpage vs développement).
Avant tout cela on a établi une roadmap, une vison de comment l’on va s’organiser nos sprints et leur contenu (on est sur des thématiques à ce niveau), l’on peut aussi avoir une dépendance avec un service tiers qui ne sera disponible que dans plusieurs semaines, on le positionne donc dans la roadmap, la roadmap n’est pas figée dans le temps idem pour le reste.
Je ne sais pas si c’est une bonne pratique, nos epics par exemple peuvent être sur plusieurs sprints mais ce que l’on livre dans un sprint est fonctionnel et testable même si derrière c’est mocké.
Nous ce que l’on recherche dans une démarche agile c’est du feedback et comme l’on dit fermer des portes, c’est réalisé, c’est tester on y revient pas (ou presque).
1 « J'aime »
Je pense qu’on est dans la même logique
Si tu veux une réponse « bonne pratique »: Les deux backlogs sont à prioriser par ordre de livraison.
Sur ce thème et pour le Product Backlog je trouve cette ressource particulièrement pertinente : 8 Different Ways to Organize Your Backlog
https://miro.com/miroverse/8-different-ways-to-organize-your-backlog/
Hum… ça manque un peu de nuances quand même. Y’a (presque) aucun désavantage mentionné =/
L’ordre chez moi est généralement « ce qu’on veut absolument faire est en haut » dans le sens « le truc en haut, c’est ce qui doit être fait quitte à ce que ça ne soit que ça ».
Et chacun de ces éléments contient une découpage technique pour le réaliser. Ces tâches sont généralement ordonner par ordre logique de construction.
Est ce qu’on peut donc résumé en disant que tu ordonnes par ordre de livraison ou y’a t’il plus de subtilité ?
Oui. Pour la forme je préciserai : par ordre supposé de livraison.
Voir même, soyons fou : par ordre de recueil du feedback.
3 « J'aime »
Le supposé est effectivement sous-entendu
1 « J'aime »