Parcourez tous les articles dans cette catégorie
« On a besoin d'un sprint de dette technique. » Cette phrase est prononcée dans des centaines d'équipes chaque trimestre. Ce qui se passe ensuite : deux semaines de refactorisation sans direction claire, dont la valeur est impossible à communiquer au management, et qui ne change pas fondamentalement les problèmes les plus douloureux.
Combien de fois avez-vous eu un 1-on-1 où votre manager a ouvert Jira pour passer en revue vos tickets en cours ? Cette réunion aurait pu être un email, ou une consultation de tableau Kanban. Le 1-on-1 qui ressemble à un rapport de statut est un 1-on-1 gâché.
Votre équipe a une page Notion avec le plan du prochain trimestre. Elle a été rédigée la semaine dernière. Trois personnes ont ajouté des commentaires. Deux ont mis un emoji. Le plan n'a pas changé. Personne n'a pris de décision. C'est l'async sans contrôle : beaucoup d'activité, peu de résolution.
Quand est-ce qu'une epic est terminée ? La question devrait avoir une réponse simple. En pratique, dans la plupart des équipes, c'est une longue conversation. L'epic grandit, se divise, se réouvre, migre d'un sprint à l'autre. Ce n'est pas un problème d'implémentation Scrum. C'est un problème de définition.
« Notre velocity est de 42 points par sprint. » Cette phrase est prononcée avec fierté dans des centaines de réunions de planification chaque semaine. Elle dit quoi, exactement ? Que l'équipe ferme des tickets à un rythme cohérent. Ce qu'elle ne dit pas : si ces tickets créent de la valeur, si les estimations sont réalistes, si l'équipe est épanouie.
Combien de fois avez-vous vu une release se transformer en fourre-tout de fonctionnalités semi-terminées, de corrections de dernière minute et de tickets migrés depuis trois sprints précédents ? La release a perdu son sens parce qu'elle n'est utilisée que comme conteneur de livraison, pas comme outil de pilotage.
« En tant qu'utilisateur, je veux pouvoir me connecter afin de pouvoir accéder à mon compte. » Ce ticket a été écrit des millions de fois. Il ne décrit rien d'utile sur ce que le développeur doit faire. C'est le problème central de la user story comme unité de travail.
