Tous les chemins mènent à Rome, mais avec Scrum, on y arrive plus vite.
Ceux qui ont décidé de franchir le pas et font leurs premiers pas n'ont pas la tâche facile au début. Nous partageons volontiers notre expérience pour que Scrum fonctionne aussi chez vous plus facilement et sans accroc. Grâce à ces deux conseils, votre rétrospective et votre Sprint Planning réussiront mieux.
1. Rétrospective
Pour la conduite de 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 toutes les choses perçues comme positives et négatives 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 nombre de post-it suffit généralement à voir quel thème doit avoir la plus haute priorité. La règle est donc : plus il y a de post-it sur un thème, plus ce thème est important. Ensuite, chaque thème est discuté systématiquement, 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 directement intégrée au sprint suivant et consignée dans le Sprint Backlog.
Les questions suivantes sont standard dans 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 ?
- Que n'avons-nous pas encore compris ?
Si l'on veut rendre la rétrospective encore plus facile ou plus ludique, les possibilités sont innombrables. Par exemple, le Scrum Master dessine une étoile de mer sur un tableau blanc. Les questions sont inscrites sur les bras de l'étoile de mer, puis les post-it sont classés selon les questions.
- Qu'est-ce qui s'est bien passé, que devons-nous poursuivre ?
- Quelle activité devons-nous intensifier ?
- Quelle activité devons-nous réduire ?
- Quelle nouvelle idée devons-nous adopter immédiatement ?
- Qu'est-ce qui s'est moins bien passé, que devons-nous arrêter ?
2. Sprint Planning
Pour estimer les stories, les tâches et les bugs du Product Backlog lors du Sprint Planning, nous recommandons ce qui suit 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 faire d'estimation. En revanche, dans le 2e sprint, on pourrait attribuer des story points à une story du 1er sprint. 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 uniquement de la responsabilité de l'équipe de développement. Ni le Product Owner ni le Scrum Master ne doivent s'immiscer dans cette estimation. S'ils le font malgré tout, il peut arriver que des tickets ne puissent pas être terminés dans un sprint, c'est-à-dire qu'ils soient sous-estimés.
L'expérience montre qu'il vaut toujours mieux faire une estimation prudente plutôt qu'optimiste. Même lorsque les tickets semblent 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, le sprint tourne au stress pour les développeurs, ce qui entraîne des erreurs et un travail peu soigné, ou tout simplement des stories qui ne peuvent pas être terminées.
kununu