« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
| Ligne 36 : | Ligne 36 : | ||
* '''Appeler Kanban "Scrum" :''' le backlog de sprint ressemble à un collection aléatoire d'éléments et aucun objectif de sprint n’est défini. (Si c’est la façon naturelle de terminer votre planification de sprint I, vous avez probablement atteint le dernier degré d'utilité de Scrum en tant que cadre de développement de produit. En fonction de la maturité de votre produit, Kanban pourra s’avérer une meilleure solution. Sinon, ce caractère aléatoire pourrait témoigner d'un Product Owner faible qui écoute trop les parties prenantes au lieu de prioriser correctement le backlog produit.) | * '''Appeler Kanban "Scrum" :''' le backlog de sprint ressemble à un collection aléatoire d'éléments et aucun objectif de sprint n’est défini. (Si c’est la façon naturelle de terminer votre planification de sprint I, vous avez probablement atteint le dernier degré d'utilité de Scrum en tant que cadre de développement de produit. En fonction de la maturité de votre produit, Kanban pourra s’avérer une meilleure solution. Sinon, ce caractère aléatoire pourrait témoigner d'un Product Owner faible qui écoute trop les parties prenantes au lieu de prioriser correctement le backlog produit.) | ||
* '''Travail inachevé :''' les user stories inachevées et les autres tâches du dernier sprint sont transférées dans le nouveau sprint sans discussion. (Il peut y avoir de bonnes raisons à cela, par exemple, la valeur de la user story n’a pas changé. Cependant, cela ne devrait pas être un automatisme, souvenez-vous de [https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy l'erreur de jugement sur les coûts irrécupérables].) | * '''Travail inachevé :''' les user stories inachevées et les autres tâches du dernier sprint sont transférées dans le nouveau sprint sans discussion. (Il peut y avoir de bonnes raisons à cela, par exemple, la valeur de la user story n’a pas changé. Cependant, cela ne devrait pas être un automatisme, souvenez-vous de [https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy l'erreur de jugement sur les coûts irrécupérables].) | ||
* '''Changements de dernière minute :''' le Product Owner essaie d’intégrer certaines user stories de dernière minute qui ne satisfont pas à la définition du prêt. (Le Product Owner a principalement pour prérogative d’apporter ce type de modifications afin de s’assurer que l’équipe de développement ne travaille que sur les user stories les plus intéressantes à un moment donné. Cependant, si l'équipe Scrum pratique régulièrement des sessions d'affinage du backlog produit, cela devrait rester une exception rare. Si cela se produit fréquemment, cela signifie que le Product Owner a besoin d'aide pour la définition des priorités et la communication avec l'équipe. Ou le Product Owner a besoin d'aide pour savoir plus souvent dire "non" aux parties prenantes.) | |||
* | |||
=== Antipatterns de planification du sprint par l'équipe Scrum === | === Antipatterns de planification du sprint par l'équipe Scrum === | ||
== Conclusion == | == Conclusion == | ||
