Nous souhaitons réaliser ce projet avec ce budget, et nous souhaitons le réaliser en suivant la méthode Scrum/Agile!

Si vous êtes familier de cette phrase (sur laquelle nous pourrions débattre très longuement), vous êtes au bon endroit et êtes le/la bienvenu(e) sur cette suite d'articles consacrée à l'utilisation d'Azure Boards, le module de suivi de projet d'Azure DevOps, afin de nous permettre de nous organiser au mieux.

Disclaimer: Ces articles sont issus d'une opinion très personnelle sur laquelle vous avez le droit de ne pas être d'accord (c'est même vivement recommandé !). J'espère seulement que ce partage d'expérience pourra vous permettre de prendre vos propres décisions.

Préambule: Pourquoi faire un Sprint Planning ?

Je considère le Sprint Planning comme l'un des cérémonials les plus importants de Scrum. Parmi tous les bénéfices qu'il fournit, mes préférés sont :

• En tant que développeur, je peux me focaliser sur la réalisation des tâches à faire et être plus productif. Cela est possible notamment car nous nous sommes assurés que les US (User Stories) sont claires, et car nous avons déjà listé toutes les tâches techniques à effectuer.
• En tant que Product owner, j'ai plus de temps pour rester concentrer sur la préparation des Sprint futurs, plutôt que de devoir expliquer quotidiennement les US du Sprint courant.
• Le scope initial + l'estimation des tâches nous permet d'avoir un point de départ pour surveiller notre performance (le fameux Burndown), et permet également de fournir plus de transparence aux personnes extérieures à l'équipe.

Ceci étant dit, si la plupart du temps tout le monde est convaincu de sa nécessité, cela ne signifie pas que l'on peut le dérouler n'importe comment. L'organisation du Sprint planning comporte de nombreux challenges, et réussir à le faire tenir sur une durée relativement courte me semble être l'un des plus importants !

Dérouler un Sprint Planning sur une durée courte demande de la préparation

• C'est parti pour une nouvelle journée entière de Sprint Planning ! Haut les cœurs !
• ...

Bon, les réunions sont très consommatrices de temps. Et *spoiler alert* le Sprint Planning est comme toutes les autres réunions : Si elles ne sont pas préparées en amont, elles seront bien souvent longues et inefficaces (et finiront d'achever toute bonne volonté de la part de vos équipiers).

Je préfère prévoir clairement quelques journées de préparation pour le Sprint suivant, et être capable d'avoir un Sprint Planning complet (i.e. avec la vision complète du Sprint) en 1 demi-journée, plutôt que de faire "perdre du temps" à l'équipe entière sur 1 journée complète (je vous laisse faire les maths), avec en plus un fort risque de ne pas avoir de vision claire sur le Sprint en sortie...

Je suis également très embêté lorsqu'une nouvelle US est présentée, et que nous faisons perdre du temps aux personnes potentiellement moins concernées (PO, Designer, personnes avec moins d'affinité sur le module touché, etc.) en débattant en séance sur la manière de l'implémenter. La repousser au prochain Sprint serait à la limite plus acceptable, mais si c'est une US cruciale pour le développement des autres US du Sprint, que doit-on faire ?

Pour être transparent, si j'étais dans un contexte sans contrainte de Temps (notion souvent très fortement couplée avec la notion Coût), je préférerai suivre les 2 scénarios mentionnées précédemment, mais bizarrement je suis rarement tombé sur ce genre de projet :)

Et je pourrais continuer encore longtemps (Envoyez moi un tweet pour poursuivre la discussion), mais voyons plutôt comment nous pouvons essayer de réduire la durée et améliorer l'efficacité de notre Sprint Planning.

Mes User Stories idéales

Et oui personnellement je pense que même en Agile, nous avons besoin de plus qu'une phrase gribouillée sur un post-it pour être capable de donner une estimation qui tient la route (plus d'infos à ce sujet dans un précédent blog post Doit-on écrire des spécifications lorsqu’on utilise des User Stories ?).

Mais un Sprint Backlog n'est pas non plus juste une liste de règles métiers écrites un peu au hasard. Laissez-moi vous présenter la manière dont j'ai l'habitude de les organiser :

1. Je préfère un Titre concis, avec des mot-clés faciles à retenir et qui pourront être réutilisés simplement par l'équipe pour communiquer. J'aime également ajouter des [Tags] pour savoir facilement à quelle partie de l'application l'US se refère.
2. La partie Critères d'Acceptation est clairement le champ où je suis le plus exigeant. J'utilise le format très populaire de En tant que, Je souhaite, Afin de pour comprendre facilement le Qui ?, le Quoi ? et le Pourquoi ? (Et j'insiste particulièrement sur le Pourquoi ? afin de permettre au relecteur d'avoir une vision plus globale et pas simplement faire quelque chose parce qu'on lui a dit de le faire...). Si besoin j'ajoute également dans ce champ quelques règles métiers supplémentaires, avec un impact faible (si l'impact est trop important, je crée une US dédiée).
3. Dans la Description, je demande souvent les liens vers les maquettes, ainsi que toute précision / direction technique.
4. Très important également, si l'US est considérée comme "non prête à être développée", je m'attends à ce qu'il y ait un Commentaire explicitant ce qu'il manque pour qu'elle soit prête, mentionnant les personnes concernée, avec en bonus la personne principale dans le champ Assigné à.
5. C'est probablement spécifique à notre organisation, mais j'aime souvent savoir quels type d'affinités nécessite l'US (Dev Front-End, Back-End, Design, Suivi de projet, etc.) afin de pouvoir appliquer quelques optimisations du genre "Le prochain Sprint contient principalement des US Back-End, du coup il est nécessaire de réfléchir aux sujets sur lesquels les devs Front-End pourront avancer !"
6. En tant que société de service (même si en général on aime pas trop employer ce terme :D), nous avons besoin de fournir des estimations de charges en jour/homme (Je n'ai pas encore trouvé de projet sur lequel nous pourrions vendre des Story Points :D). Du coup j'ai souvent tendance à rappeler notre estimation dans le champ Story Point ou Effort afin de pouvoir constater à quel point nos estimations initiales étaient bonnes ou pas :)

Comment s'organiser pour rédiger des User Stories ?

Obtenir un backlog finalisé, prêt pour le Sprint Planning est un effort d'équipe. Ci-dessous le process que je suis en général afin de réussir à l'obtenir en un minimum de temps possible :

1. Le PO (Product owner) rédige les US en premier lieu, en remplissant notamment les champs Titre, Critères d'Acceptation + règles métiers, Description avec les maquettes (si pertinent). Si le projet possède des estimations initiales, rappeler ces estimations en jour/homme dans les champs Story Point ou Effort est un must !

   • C'est très clairement consommateur de temps. Le plus gros challenge étant que dans l'idéal, l'équivalent d'au moins 2 Sprints d'US devrait être préparé pour réduire au maximum les temps morts de l'équipe.
   • Pour une équipe de 5-6 dev, prendre 1 à 2 jours sur le sujet par Sprint ne me surprend pas plus que ça.

2. Ensuite quelqu'un côté technique (Idéalement avec un peu d'expérience) les relit et vérifie que tout soit bien clair et prêt à être découpé et estimé en tâches.

   • Si ce n'est pas le cas, il faut rajouter les questions en Commentaire + mentionner les personnes concernées, ainsi que mettre en Assigned To le principal intéressé (très souvent le PO)
   • C'est l'occasion également de rajouter quelques Tags pour en savoir plus sur les affinités requises.
   • Si tout est prêt, il peut ensuite créer les Tâches techniques nécessaires pour compléter l'US, ainsi que leur rajouter une Estimation initiale
   • En dehors de tout ça, il arrive parfois qu'il faille rajouter des US d'archi techniques pour gagner en maintenance et/ou gagner du temps sur des développements similaires à l'avenir. La personne technique est responsable dans l'intégralité de ces US techniques, et devrait idéalement clairement expliciter les gains apportés sur le projet pour que le PO puisse avoir le dernier mot sur la priorisation.
   • Relire toutes les US est également très consommateur de temps, en particulier si de nombreux échanges de commentaires sont nécessaires. De 1 jour à 1 jour et demi par Sprint dédié sur le sujet me semble tout à fait correct.

Note : Créer les Tâches et les estimer en avance est clairement sujet à débat. Cependant par expérience, j'ai pu observer que même si le découpage n'est pas fait en amont, ce sont souvent ces mêmes "personnes expérimentées" qui se retrouvent à découper + estimer les tâches durant le Sprint Planning, dégageant une impression de "perte de temps" précieux, temps qu'il serait préférable de passer à expliquer leur conception et la manière de l'implémenter (tout en restant ouvert à discussion bien entendu)

C'est durant cette seconde partie de relecture technique que je trouve que ce process brille car il permet :

• De s'assurer que les US sont prêtes à être développées (car au moins 1 développeur a pu concevoir une implémentation)
• D'avoir plus de temps pour réaliser des tâches courtes en "tâche de fond" telle que :
  • Obtenir une réponse du client
  • Obtenir / Modifier des Designs
  • Prendre le temps de trouver une implémentation / architecture acceptable pour une US donnée, en demandant des retours d'expérience à ses collègues en interne par exemple, etc.

Pour résumer

C'est tout pour cette première partie à propos de la Préparation du Sprint Planning avec Azure Boards / DevOps

J'espère que cela a pu vous apporter quelques idées à mettre en place pour améliorer l'organisation du travail en équipe (ou vous a permis de vous rassurer sur votre propre implémentation)

La prochaine fois, j'aimerais aborder le sujet de "Comment obtenir une Capacité réaliste avec Azure Boards"

N'hésitez pas à montrer votre désaccord ou toute autre opinion dans les commentaires ou par message via Twitter @vivienfabing.

Que le code soit avec vous !