Dans le manifeste "Scrum", tous les rituels sont timeboxés et limités dans le temps, y compris la durée des sprints qui doivent avoir la même cadence. Du coup on ne peut pas prolonger la taille d'un sprint même si on n'a pas terminé et achevé tout le Scope du "Sprint Backlog".
Au niveau de la séance du "Sprint Planning", les membres de l'équipe Scrum travaillent ensemble pour définir le contenu du "Sprint Backlog", ainsi que l'objectif du Sprint en question, en parallèle l'équipe de développement utilise sa capacité pour sélectionner les "User Stories" dont elle sera capable de les traiter et les réaliser pour les mettre en statut "DONE" à la fin du Sprint, du coup si une "User Story" n'est pas terminée en fin du sprint, que doit-on faire ?
Si une "User Story" n'est pas terminée à la fin du Sprint, alors la première des choses à faire c'est de la mettre en haut du "Product Backlog", et voir avec le "Product Owner" lors du "Sprint Review" ou le "Sprint Planning" s'il envisage la faire passer au Sprint suivant ou pas, car on peut se confronter à une revue de l'ordre de priorité qui va dé-prioriser cette User Story en question, par conséquent elle sera planifiée dans un futur "Sprint", ou bien un changement du besoin impactant la demande sera effectué.
Plusieurs développeurs sous-estiment souvent la quantité de travail incomplète et inachevée, et chez pas mal des équipes que j'ai déjà côtoyé, j'entends toujours la phrase : "On a terminé presque 90% du travail, il reste que 10%", ou bien elles ajoutent un 3ème statut pour une demande à part "Terminée" et "Non terminée" qui est le statut "Presque terminée". Alors que dans le développement logiciel agile, le statut d'une demande ou fonctionnalité est "BINAIRE". Terminée ou non terminée, et rien entre les deux....
Si l'User Story est toujours prioritaire et d'actualité, alors là il faut la faire passer au prochain sprint, sachant qu'aucun point d'histoire de cette demande n'est donc marqué comme terminée, car il faut l'intégrer dans le Sprint Backlog avec la même estimation initiale, et cela même si l'équipe de développement prétend qu'une partie de travail a été déjà faite et achevée.
Conclusion :
l'objectif de chaque équipe de développement agile en Scrum est de bien achever tout le travail planifié dans un Sprint, et les User Stories non terminées dans un cycle itératif doivent être des cas exceptionnels. Pour cela on peut utiliser le KPI de "Prédictibilité" pour comparer à chaque fois le travail planifié avec celui réalisé en fin de Sprint.
L'objectif de la Rétrospective est de bien s'améliorer en profitant de notre expérience pour plus d'efficacité et de performance. comme ça on analyse à chaque fois les causes d'un travail non achevé et on essaye de s'améliorer en cherchant des solutions et bonnes pratiques à mettre en place, et tout ça dans le cadre du Processus Empirique de l'agilité.
コメント