On a fait la phase de cadrage pour se transformer en agile, on a bien défini les enjeux de notre écosystème, nous sommes tous d'accord sur le choix de "Scrum" comme cadre méthodologique à déployer pour travailler en agile et construire notre produit cible.
Bien sur avant de se lancer dans le développement et la réalisation, et parmi les premières questions d'or à la quelle il faut donner plus de temps et répondre c'est la taille de nos cycles itératifs, ou tout simplement la durée de nos Sprints.
Déjà on peut dire qu'il n'existe pas une réponse générale ou universelle, et même en jetant un coup d'œil sur le "Scrum Guide", on va déduire que la taille peut aller d'une à 4 semaines. Dans cet article je vais essayer de vous donner quelques critères sur lesquels vous pouvez se baser pour déterminer la taille de vos Sprint, cette taille qui n'est pas du tout graver dans le marbre, mais plutôt vous pouvez la changer si nécessaire.
Plusieurs facteur et critères peuvent intervenir pour décider la taille du Sprint, en occurrence :
La disponibilité des parties prenantes pour assister à la revue de Sprint et d’autres éventuels rituels (Affinage, Priorisation, …Etc.).
Le niveau de découpage des User Stories par l’équipe de développement (Taille des demandes fonctionnelles).
Le temps nécessaire pour terminer et achever une User Story (Statut DONE & DoD).
La fréquence de changement du besoin par les parties prenantes.
La fréquence des Releases souhaitée par le client.
L’implication des utilisateurs finaux pour donner leurs Feedbacks.
La taille de l’équipe de développement (Temps de synchronisation).
La Durée maximum pour traiter un changement du besoin (ne doit pas prendre la totalité du temps alloué au Sprint).
Le time box des rituels à l’occurrence le Sprint Planning, le Sprint Review, et l‘affinage du Product Backlog.
En général la taille de Sprint doit être assez longue pour produire et livrer un incrément produit portant de la valeur métier, et assez courte pour que le changement du besoin soit plus lent.
Sans oublier les deux principes d'or qu'il faut respecter à savoir :
Le contenu d'un Sprint ne doit pas changer après son démarrage.
Tous les Sprints doivent avoir la même durée.
Conclusion :
Chaque équipe a son propre environnement de travail et contexte (taille, technologie, complexité, disponibilité des parties prenantes, …Etc.).
Choisissez une taille adéquate à votre équipe, passer des Sprint pour tester, et ajuster la taille si besoin tout en se basant sur le processus empirique de l’agilité visant une amélioration en continu.
Chez plusieurs équipes agiles que j'ai côtoyé, 3 semaines est la taille fréquente que je vois toujours déployée.
Comments