Tous les chemins mènent à Rome, mais avec Scrum, on y arrive plus vite.
Quiconque a décidé de passer à Scrum et fait ses premiers pas n'a pas la tâche facile au début. Nous vous donnons ici un petit coup de pouce pour que Scrum fonctionne aussi chez vous plus facilement et sans accroc.
Grâce à ces deux conseils, votre rétrospective et votre Sprint Planning seront plus réussis.
1. Rétrospective
Pour mener la rétrospective, la démarche suivante a fait ses preuves chez nous : au début de l'événement, chaque membre de l'équipe Scrum reçoit des Post-it et un stylo. Il y note tous les éléments perçus comme positifs ou négatifs au cours du dernier sprint. Chaque membre présente ensuite brièvement ses points et colle les Post-it sur un tableau blanc. Lorsque tous les membres ont présenté leurs points, les Post-it sont triés par thème ; le plus souvent, le simple nombre de Post-it permet déjà de voir quel thème doit avoir la priorité la plus élevée. La règle est donc la suivante : plus il y a de Post-it sur un thème, plus ce thème est important. Ensuite, chaque thème est discuté de manière systématique, de la priorité la plus haute à la plus basse. Les propositions d'amélioration sont consignées par écrit et au moins l'une d'entre elles est intégrée directement dans le sprint suivant et inscrite dans le Sprint Backlog.
Les questions suivantes font partie du standard Scrum :
- Qu'avons-nous si bien fait que nous devons en parler pour ne pas l'oublier ?
- Qu'avons-nous appris ?
- Que devons-nous faire différemment à l'avenir ?
- Qu'est-ce que nous n'avons pas encore compris ?
Il existe d'innombrables possibilités pour rendre la rétrospective encore plus facile. Par exemple, les questions suivantes peuvent être affichées sur un tableau blanc. Tous les membres de l'équipe peuvent y répondre.
- Qu'est-ce qui a bien fonctionné, que devons-nous poursuivre ?
- Quelle activité devons-nous intensifier ?
- Quelle activité devons-nous réduire ?
- Quelle nouvelle idée devons-nous reprendre immédiatement ?
- Qu'est-ce qui a moins bien fonctionné, que devons-nous abandonner ?
2. Sprint Planning
Pour estimer les stories, tâches et bugs du Product Backlog pendant le Sprint Planning, nous recommandons la démarche suivante pour le Planning Poker. Utilisez des tickets déjà estimés comme référence pour votre estimation des Story Points. S'il s'agit du 1er sprint, il peut être judicieux de ne pas encore y faire d'estimation. En contrepartie, dans le 2e sprint, des Story Points issus du 1er sprint peuvent être attribués à une story. Celle-ci peut alors servir de référence pour l'estimation des stories du 2e sprint.
Veillez à ce que l'estimation des tickets relève de la seule responsabilité de l'équipe de développement. Ni le Product Owner ni le Scrum Master ne doivent intervenir dans cette estimation. Cela pourrait conduire à ce que des tickets ne puissent pas être terminés dans un sprint parce qu'ils ont été sous-estimés.
L'expérience montre qu'il vaut toujours mieux faire une estimation prudente et pas trop optimiste. Même lorsque des tickets semblent avoir été examinés en détail, des événements et des difficultés imprévus surviennent souvent et retardent le développement. Si de nombreux tickets sous-estimés s'accumulent dans un sprint, celui-ci tourne au stress pour les développeurs, ce qui entraîne des erreurs et un travail bâclé, ou tout simplement des stories qui ne peuvent pas être terminées.
Vous n'en êtes qu'au tout début et tout cela vous semble du chinois ?
Nous proposons des formations Scrum pour vous faciliter l'entrée dans le sujet.
kununu