Travaux planifiés et non planifiés en Scrum
La plupart des équipes qui commencent à travailler avec Scrum comprennent leur backlog et ce qu'on appelle le « travail planifié ». Ce sont les tâches que tout le monde a rassemblées ensemble et qu'ils ont parfaitement comprises. Et puis il y a tout le reste… Ce sont ces choses auxquelles les nouvelles équipes Scrum doivent faire attention lors de leur premier Sprint. Toutes les tâches qu'ils effectuent indépendamment du travail planifié pour ce Sprint sont listées dans la colonne « travail non planifié » avec le nombre d'heures nécessaires.
Après le premier Sprint, les équipes sont souvent totalement surprises par tout ce qui s'accumule. La plupart du temps, ce sont diverses tâches qu'on effectue depuis toujours au quotidien ou chaque semaine – on les appelle souvent les tâches « Business-as-Usual » (BAU), mais elles peuvent avoir d'autres noms dans d'autres entreprises. Il y a aussi les réunions ad hoc et d'autres choses que nous faisons sans trop y réfléchir. Ce peuvent être des tâches BAU ou simplement des perturbations ou des interruptions.
Il y a également les urgences qui doivent être traitées immédiatement. Souvent, cela relève du « Support » – mais cela pourrait porter n'importe quel autre nom.
Certaines de ces choses nous sont déjà connues lors du Sprint Planning . On les ajoute alors à son Sprint Backlog comme partie des engagements. Si elles reviennent régulièrement, il serait peut-être judicieux de créer une colonne dédiée et de réserver une certaine capacité pour ces éléments.
Que faire en cas de travaux imprévus en Scrum ?
Organisez une réunion pour examiner de plus près les tâches récurrentes et découvrir comment améliorer le travail avec celles-ci. L'objectif est de les automatiser ou au moins de les réduire autant que possible.
Les éléments qu'on ne peut pas prendre en compte lors du Sprint Planning sont ceux qui surviennent pendant le Sprint et ne peuvent pas être prévus. Nous les appelons « unplanned » ou « non planifiés ». Chaque équipe a une part de ce travail non planifié et doit trouver comment le gérer. Là aussi, vous devriez régulièrement réfléchir à ce que vous pouvez faire pour réduire ce travail non planifié autant que possible. Plus une équipe a de travail non planifié, moins elle peut prendre de travail supplémentaire. Idéalement, la majeure partie du travail d'une Scrum Team devrait être du travail planifié. Chaque équipe doit évaluer ses capacités et trouver la meilleure façon de travailler avec.
Voici quelques méthodes que j'ai déjà vues chez des équipes :
Limites et règles
Tout travail non planifié est noté sur le board et priorisé. Cependant, la colonne Work-in-Progress a une limite sur le nombre de travaux pouvant être traités simultanément, par exemple deux. On ne peut donc travailler que sur deux choses différentes en même temps. Le reste de l'équipe peut ainsi se concentrer sur les travaux planifiés pour le Sprint. On peut aussi définir des règles sur quels éléments non planifiés peuvent être ajoutés au board et quand, etc.
Une personne par jour/semaine/Sprint
On peut aussi établir un planning qui définit qui est assigné quand pour travailler sur les éléments non planifiés. Ainsi, le reste de l'équipe peut se concentrer sur les travaux planifiés. Si la personne ne comprend pas quelque chose ou rencontre un problème, elle peut demander de l'aide aux autres membres de l'équipe. On peut alterner quotidiennement, hebdomadairement ou à chaque Sprint.
Un créneau horaire défini
On peut aussi définir un créneau horaire pour les travaux non planifiés. Par exemple entre 09h00 et 11h00, le reste de la journée étant réservé aux Sprint Items.
Jours fixes
On peut aussi prévoir certains jours de la semaine pour travailler sur les éléments non planifiés – par exemple mardi et jeudi. Tous les autres jours ouvrés sont réservés aux travaux planifiés.
Les Scrum Teams peuvent alterner
Quand plusieurs Scrum Teams travaillent sur le même Backlog, les équipes peuvent alterner entre elles pour le travail sur les éléments non planifiés. L'équipe A travaille donc ce Sprint uniquement sur les éléments non planifiés et l'équipe B travaille sur les Backlog Items.
Vous avez sûrement remarqué que dans tous les exemples, les équipes disposent d'une période concrète pour travailler sur les Backlog Items. Il n'y a pas de schéma fixe pour cela et il existe certainement d'autres possibilités que celles mentionnées ci-dessus. Si vous rencontrez aussi ce problème, essayez simplement quelques-unes de ces suggestions et découvrez ce qui fonctionne le mieux pour vous.
Ce texte provient du blog de Growing Agile et nous a été mis à disposition.
