Les itérations en pratique

Les itérations en pratique

Dans une optique Scrum, il revient au Product Owner de définir les expériences utilisateurs qu’il veut mettre en place, mais c’est au Scrum Master de comprendre les tâches qui en découlent, de les prioriser, puis de les répartir entre les membres de l’équipe. Ce n’est qu’une fois que le projet est bien délimité qu’on peut faire place aux itérations.

Bien se préparer à un sprint

C’est majoritairement au Scrum Master que revient la responsabilité de bien préparer les sprints, par l’intermédiaire du Backlog. Plus précisément, il est nécessaire d’y trouver :

  • L’intégralité des User Stories demandées par le Product Owner, qui sera présent lors de la réunion pour répondre à toute question et spécifier ses besoins
  • Les étapes de développement nécessaires pour les mettre en place
  • Une attribution hiérarchisée des tâches aux membres de l’équipe


Tout le monde peut se reporter à ce document et comprendre comment son propre travail s’imbrique avec celui des autres. La méthode Scrum met l’accent sur la communication, et ce n’est pas par hasard : une équipe soudée avec un but clair ne pourra que proposer des résultats
cohérents.

Il est également nécessaire de déterminer la durée du sprint. On retrouve des durées variables, entre 2 et 4 semaines, en fonction de la complexité des tâches ; mais pour un projet très sensible aux changements, on pourra tout aussi bien trouver un sprint sur une semaine !

Les étapes d’un sprint

Tout sprint digne de ce nom commence par un Sprint Planning Meeting, ou réunion de planification. C’est lors de cette rencontre initiale entre tous les membres de l’équipe qu’il est le plus important de s’exprimer sur ce qu’on connaît des étapes à franchir pour chaque User Story. Cela permet de revoir la priorisation des tâches, mais aussi de les attribuer aux membres les mieux placés pour le faire.

Tous les jours de sprint, on aura un Meeting Scrum : une réunion courte et dynamique qui permet à chacun de s’exprimer sur trois points de manière concise. Idéalement, cette réunion se fait debout pour permettre à tout le monde de se rendre compte du temps qui passe. Chaque membre devra indiquer :

  • Ce qu’il a réussi à accomplir dans sa journée ; c’est l’occasion de le féliciter et d’inscrire ses accomplissements dans le Burndown Chart.
  • Les problèmes qu’il a rencontrés ; c’est une opportunité de suggérer des pistes pour les résoudre. Si les problèmes persistent d’un jour sur l’autre, il est tout à fait envisageable que le Scrum Master ré-assigne des membres de l’équipe à cette nouvelle tâche.
  • Ce qu’il compte faire lors de la prochaine journée de travail ; c’est un bon moment pour faire des remarques sur les écueils à éviter, ou sur la coordination des autres parties du projet.


Ce Meeting ne devrait pas prendre plus de deux minutes par personne. C’est aussi un bon moment pour faire évoluer le Backlog Product et y ajouter de nouvelles tâches qu’on ne pouvait pas prévoir avant de se plonger dans le projet.

Lorsque le temps du sprint est écoulé, il est l’heure de regarder les progrès effectués et de livrer cette nouvelle itération de produit au client.

La fin du sprint : récapitulatif et suite

L’heure sonne, c’est la fin du sprint : le Scrum Master organise un Sprint Meeting Review lors duquel on va pouvoir effectuer la présentation des éléments développés au Product Owner.

Lors de cette réunion particulière, il est primordial de pouvoir présenter une démonstration des avancées réalisées pendant le sprint. C’est sur cette base que le Product Owner pourra faire des retours constructifs.

De plus, c’est le moment idéal pour s’assurer que les visions de tout le monde sont toujours bien alignées : les objectifs ont-ils changés ? La priorisation des tâches est-elle toujours d’actualité ? Quelles sont les évolutions qu’a pu connaître le marché, et qui risquent d’avoir un impact sur le prochain sprint ?

Tous ces éléments sont consignés dans le Backlog Product, et seront utilisés comme base pour le prochain sprint. Pour en apprendre davantage sur le Backlog, nous vous conseillons de consulter notre article dédié à ce sujet.

Cette approche permet une amélioration continue d’un produit, tout en gardant une adaptabilité et une souplesse au contact des défis du marché.