Introduction à Scrum par la pratique Florence Chabanois (25/06/09)
Bilan de la soirée Deux itérations d’effectuées IT1 : Rythme soutenable et soutenu : presque tout a été fait une story non validée car non-conforme aux specs (muret de la même hauteur que barrière) Rétro #1 : manque de communication entre équipes IT2 : Un petit moins de points embarqués Beaucoup moins de points accomplis Une grosse story non validée car non-conforme aux specs, bien qu’elle ait été écrite sur un post it (il manquait un étage à l’église/école)
Bilan de la soirée Au sujet de l’évaluation de complexité Il vaut mieux mesurer la faisabilité d’une story avant de l’évaluer (regarder qu’on a les légos / ressources qu’il faut). Cf fenêtres, suffisamment de briques pour les murs, etc. Une story sans dessins est plus difficile à évaluer => plus de questions. Et/Ou une complexité maximum. Découper la story en tâches aide à avoir une complexité plus précise. Une grosse story peut coûter cher si elle n’est pas accomplie (cf l’église de l’IT2). Ne pas hésiter à la découper en plus petites stories validables pour avoir un maximum de points. La part d’inconnu d’une story peut être levée en introduisant une story intermédiaire (une étude d’impact ou un prototype)