Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie mais il y a 2 principes pour en déterminer la valeur optimale pour votre projet.
Sprint Length: What Length is the Right Length?
http://blog.3back.com/scrum-tips/sprint-length-what-length-is-the-right-length/ Par Docteur Dan Rawsthorne
On me demande souvent, ‘Combien de temps devrait durer un Sprint pour mon équipe ?’ Et ‘le Sprint doit-il être de durée fixe ?’. Je constate qu’il ne suffit pas de répondre : « N’y réfléchissez-y pas trop longtemps. Si vous utilisez un environnement raisonnable et un langage de développement comme Java ou dot-net, utilisez une durée de Sprint de deux semaines. Cela semble marcher pour la plupart des équipes, mais certains utilisent une semaine ou trois semaines. Voyez simplement ce qui vous convient. »
Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie.
Deux principes sur la durée
Il y a deux principes pour déterminer la durée d’un Sprint.
- Le Sprint ne devrait pas être changé après son démarrage.
- Les Sprints devraient être de même durée.
Je pense que la première règle est claire et directe. Ce serait tricher que de changer la durée du Sprint après qu’il ait commencé. Si l’équipe ferme les yeux sur le changement de la durée de Sprint, elle sera tentée de changer la définition de « Done » pour permettre certains changements de contenu. Ceci est une mauvaise chose: La chose correcte à faire est d’ajouter une autre histoire utilisateur (User story) à l’Arriéré de produit (Product Backlog).
Quant aux Sprints devant tous être de même durée, c’est un peu plus délicat. J’ai déjà dit qu’un Sprint de démarrage pourrait être de seulement une semaine, donc, clairement je ne suis pas totalement inflexible sur le fait que tous les Sprints devraient être de même durée. Puisqu’un Sprint est une boucle de retour d’information, l’équipe doit prendre en compte les parties prenantes. Avoir une durée de Sprint fixe donne aux parties prenantes un rythme constant pour les revues de livrables, ce qui est réconfortant et installe une routine familière. Cependant, avoir des durées de Sprint différentes pour des Sprints spécialisés, comme la prise en compte des périodes de fêtes (ou des vacances), ou une autre raison dont l’équipe et les parties prenantes peuvent convenir, ne me semble pas être une terriblement mauvaise chose.
Est-ce assez long ?
Un Sprint doit être assez long pour vraiment achever des histoires (user stories). C’est-à-dire l’équipe doit pouvoir amener ses histoires jusqu’à leur état fini (« done »). C’est une règle dans Scrum qu’un Sprint ne devrait jamais excéder un mois. En général, la longueur de Sprint devrait être approximativement de trois fois le temps nécessaire à analyser et réaliser totalement une histoire de taille moyenne. Ceci semble donner assez de flexibilité dans le système pour permettre à l’équipe de s’auto-organiser pour obtenir un travail fini. Mon expérience est qu’une histoire prend environ 2-3 jours pour une équipe typique qui est bien en place, donc une longueur de Sprint raisonnable est deux semaines. Cependant, les environnements sont différents; certains sont plus faciles (ou plus difficiles) que d’autres. Je m’attends donc à ce que les longueurs de Sprint d’une équipe varient largement en fonction de ces différences d’environnement.
Est-ce assez court ?
La durée de Sprint devrait être suffisamment courte pour que le changement d’avis sur les besoins soit plus lent que la durée du Sprint. C’est-à-dire, si la durée de Sprint est de deux semaines, l’équipe espère que les changements de besoins arrivent plus lentement que toutes les deux semaines. Ce qui veut dire que les parties prenantes peuvent attendre jusqu’à la fin du Sprint pour voir leur ‘nouveau truc’ délivré avant de vouloir le changer.
Dans l’environnement business actuel, il est typique que la modification de besoins soit trop rapide pour le Sprint. Il y a des bogues à réparer dans d’autres systèmes que l’équipe maintient, il y a des cas d’urgence partout dans l’organisation à fixer et les parties prenantes changent presque constamment d’avis sur ce qui est important. Ce sont autant de raisons pour que l’équipe raccourcisse la durée de Sprint ou celle du cycle de planification.
Des choses se produisent et les équipes développent des méthodes pour manager le fait que des besoins devraient être changés plus d’une fois par Sprint.
Soyez ouverts à re-planification
Parfois la durée de Sprint d’une équipe est juste trop longue pour que survivent les accords pris : la fréquence de changement des besoins est plus rapide que la longueur de Sprint ne peut le supporter. Il est tentant d’essayer de raccourcir les Sprints, mais peut-être n’est-ce pas faisable parce que les parties prenantes ne peuvent pas manager des revues plus fréquentes, ou parce que l’équipe ne peut pas développer plus rapidement.
Que fait l’équipe ?
Scrum n’est rien sinon adaptatif. En fait, si l’équipe ne s’adapte pas pour respecter ses propres réalités, ce n’est pas du Scrum. Alors, adaptez-vous… l’équipe pourrait avoir des sessions de planification de Sprint plus fréquentes – peut-être une fois par semaine.
Par exemple, si l’équipe a une durée de Sprint de deux semaines, du lundi au vendredi deux semaines plus tard. Alors, l’équipe pourrait planifier chaque lundi, et non pas seulement un lundi sur deux. Le premier lundi l’équipe remplirait son Sprint à environ 80 % de sa capacité et le deuxième lundi les membres de l’équipe se poseraient la question : « qu’ajoutons-nous maintenant ? »
Je constate que beaucoup d’équipes se sont spontanément déplacées vers ce système, donc c’est un modèle connu qui est très efficace. Il devrait faire partie de la boîte à outils du ScrumMaster.
DantotsuPM.com 