« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
| Ligne 35 : | Ligne 35 : | ||
* '''Pour quoi nous battons-nous ?''' le Product Owner ne peut pas fournir d'objectif pour le sprint, ou l'objectif de sprint choisi est faible. (Un objectif de sprint original répond à la question "Pour quoi nous battons-nous ?". Il s’agit d’une négociation entre le Product Owner et l’équipe de développement. C’est quelque chose de ciblé et de mesurable, car l’objectif du sprint et les prévisions de l’équipe vont de pair. Enfin, l’objectif de sprint est un calibrage utile pour le sprint à venir.) | * '''Pour quoi nous battons-nous ?''' le Product Owner ne peut pas fournir d'objectif pour le sprint, ou l'objectif de sprint choisi est faible. (Un objectif de sprint original répond à la question "Pour quoi nous battons-nous ?". Il s’agit d’une négociation entre le Product Owner et l’équipe de développement. C’est quelque chose de ciblé et de mesurable, car l’objectif du sprint et les prévisions de l’équipe vont de pair. Enfin, l’objectif de sprint est un calibrage utile pour le sprint à venir.) | ||
* '''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].) | ||
=== Antipatterns de planification du sprint par l'équipe Scrum === | === Antipatterns de planification du sprint par l'équipe Scrum === | ||
== Conclusion == | == Conclusion == | ||
