Rappel des objectifs d'un Sprint

Voici les objectifs d'un Sprint

  • Livrer une application partiellement terminée en respectant l'engagement du contenu (la liste des Users Story ou fonctionnalités)
  • Présenter l'application au Product Owner
  • Analyser le Sprint (Rétrospective)


Les Sprints court vs Les Sprints longs

Avantages des Sprints courts :

  • Des livraisons très fréquentes pour le Product Owner
  • Offrir la possibilité au PO de changer souvent les priorités
  • Permettre à l'équipe de s'ajuster plus souvent : plus de sprint = plus de rétrospectives
  • Avoir une bonne visibilité sur l'avancement


Inconvénients des Sprints courts :

  • Trop de changement peuvent entraîner une perte de la vision du produit à livrer
  • Les temps sont plus courts donc potentiellement il y a moins de marges de manœuvre : donc les Sprints sont plus tendus, plus de pressions potentielles
  • Le rythme du Product Owner est augmenter


Et pour les Sprint longs : c'est l'inverse.

Sympa le coup de main :-)


Alors quelle durée pour un Sprint ?

Personnellement, il n'y a pas de règles sur la durée d'un Sprint, j'ai vu des retours d'expériences sur des Sprints de 1 semaine, 2 semaines et 3 semaines.
J'utilise personnellement des sprints de 1semaine, 2 semaines ou 3 semaines en fonction :

  • de l'équipe : maturité par rapport au projet, à Scrum ...
  • du Product Owner
  • du nombre de collaborateur du Product Owner
  • du projet : développement spécifique ou intégration dans un progiciel
  • du nombre d'interconnexion avec d'autres SI
  • etc etc etc....

Par contre : je ne change pas la durée des Sprints à chaque Sprint...

Les autres critères à prendre en compte

Le résultat d'un Sprint est une application que le Product Owner va utiliser, qu'il va présenter à un échantillon d'utilisateur pour obtenir du feedback.
Si votre Product Owner prévoit de faire des présentations tous les mois à ces utilisateurs :

  • il n'est pas utile de lui livrer une application toutes les semaines
  • mais faire une livraison toutes les 4 semaines peut-être dangereux pour le projet


Plusieurs Sprint = une mise en production. Si votre processus de mis en production est long car vous devez passer par plusieurs entités :

  • Tests de montée en charge
  • Tests de métrologie
  • Audit qualité
  • etc...

Ce processus peut parfois prendre plusieurs jours ou plusieurs semaines.
Si le temps de validation pour la mise en production est de 2 semaines, il n'est pas judicieux de livrer une release tous les mois : vous allez mobiliser ces équipes suites à vos livraisons fréquentes.

Comment commencer ?

Commencer par des Sprints de 1,2 ou 3 semaines MAIS SURTOUT garder ce rythme durant au moins 4 Sprints.
Planifier toutes les réunions (planification, démonstration, rétrospective) à l'avance et communiquez sur ces dates suite à votre choix de Sprint; Cela va donner un rythme au projet : ScrumMaster, Product Owner et équipe.
Communiquez sur votre stratégie de durée de Sprint :

Nous allons utiliser 4 Sprints de X semaines, à la fin de ces 4 Sprints nous ferons un point pour définir si nous devrons augmenter ou diminuer la taille des Sprint.



En conclusion, tester, analyser et modifier (si besoin) !