Sprint Zero et pourquoi vous ne devriez PAS vous y référer

Qu'est-ce qu'un sprint

Comme décrit dans le Guide Scrumles sprints sont le cœur de Scrum, où les idées sont transformées en valeur.

Ce sont des événements d'une durée fixe d'un mois ou moins pour créer de la cohérence. Un nouveau Sprint commence immédiatement après la conclusion du Sprint précédent.

En tant que bonne pratique, le Sprint devrait inclure :

• Planification du Sprint – Pour déterminer et convenir de la portée du sprint
• Daily Scrums – Pour la collaboration d'équipe
• Révision de sprint – Pour faciliter les premiers retours et s'adapter à l'évolution des exigences
• Rétrospective de sprint – Pour encourager les améliorations de l'environnement

Pendant le sprint

• L'objectif de sprint est au centre de aucun changement qui pourrait mettre en danger l'objectif de sprint ;
• La qualité reste constante ;
• Le PProduct Backlog affiné est effectué selon les besoins ; et,
• La portée peut être clarifiée et renégociée avec le PPropriétaire du produit au fur et à mesure que l'on en apprend davantage.

Les sprints permettent la prévisibilité en garantissant l'inspection et l'adaptation des progrès vers un objectif de produit au moins tous les mois du calendrier. Lorsque l'horizon d'un sprint est trop long, l'objectif du sprint peut devenir invalide, la complexité peut augmenter et le risque peut augmenter. Des sprints plus courts peuvent être utilisés pour générer plus de cycles d'apprentissage et limiter le risque de coût et d'effort à un laps de temps plus court. Chaque sprint peut être considéré comme un projet court.

Les sprints aident l'équipe à suivre le principe agile de "livrer fréquemment des logiciels fonctionnels". Cela aide également l'équipe à vivre la valeur agile de "réagir au changement plutôt qu'en suivant un plan". Les valeurs scrum de transparence, d'inspection et d'adaptation sont complémentaires à agiles et au cœur du concept de sprints.

Sprint 0

Dans Scrum, chaque sprint est nécessaire pour livrer un incrément de produit potentiellement livrable.

Bien que Scrum ne limite l'utilisation d'aucun processus, technique ou outil, il est important de comprendre exactement ce qu'est le Sprint 0 et ce qui en est tiré. Et surtout, pourquoi les équipes font-elles référence à cette période de regroupement d'une certaine activité hors développement sous le nom de Sprint 0.

Les équipes la créent souvent pour mieux se préparer au développement et à la livraison. A partir des discussions sur divers forums, les équipes créent le Sprint 0 pour créer une vision, découvrir les exigences, créer un carnet de produit brut, analyse des exigences, feuille de route du produit, définition de l'architecture, de la pile technologique, des outils applicables, du plan UAT, etc. moment, oubliez Scrum et sortez les sprints de l'image. Quels que soient les types de projets, ne feriez-vous pas encore tout cela ? Si oui, quand le feriez-vous idéalement ? pendant la phase de planification ou créer un calendrier dédié pour cela ?

Dans un projet suivant Scrum comme cadre de développement, ces activités sont toujours applicables dans les phases respectives pour créer la feuille de route et déterminer la portée des 1 à 3 sprints initiaux et s'appuyer sur cette compréhension lors de la planification des sprints et du raffinement continu. Certaines équipes créent même le Sprint 0 dans le tableau JIRA et répertorient ces activités pour le suivi. Pire, ils leur attribuent des devis. Il est normal et nécessaire de faire toutes ces activités, mais sans les appeler Sprint 0 et les intégrer à votre tableau Scrum.

Les projets qui suivent Scrum appellent souvent cette phase Sprint 0 simplement à cause du mot à la mode et pour le fait que les événements de longueur fixe dans Scrum sont appelés Sprint. Vous pouvez même trouver des équipes créant des sprints de durcissement et de clôture.

Bien que le Sprint 0 résolve l'objectif préparatoire, il défie l'objectif et la valeur des sprints qui fournissent un incrément de produit potentiellement livrable. N'oubliez pas que l'analyse et la planification des exigences font partie du sprint et sont nécessaires pour verrouiller la portée du sprint, mais vous ne pouvez pas partir de zéro et choisir les exigences brutes le premier jour du sprint. Si vous le faites, vous compromettez le temps de développement. Limiter la planification de sprint aux premières heures du tout premier jour de sprint vous aide à renforcer la compréhension de la portée, à dimensionner et à estimer la portée du sprint. Le raffinement continu du backlog vous aide à vous préparer pour les sprints à venir. Essayez de limiter les sprints pour apporter de la valeur aux clients.

Que devrait réellement faire un projet au lieu de se référer au sprint 0 ?

Il est nécessaire de mettre davantage l'accent sur la planification du projet. Le plan de projet doit tenir compte de ces activités essentielles à la livraison pendant la phase de planification du projet. Les livrables de la phase de découverte doivent au moins inclure l'architecture, les étapes de livraison, la définition du produit et le backlog de produit de haut niveau pour au moins 2-3 sprints. Ceux-ci sont essentiels pour démarrer la prochaine phase du projet. Cette approche est également importante pour clarifier toutes les hypothèses clés et déterminer les dépendances qui pourraient compromettre le développement à un stade précoce.

Pour certaines raisons, si vous oubliez de les définir dans la phase de planification, il est toujours possible de les entreprendre dans un délai prévu, mais sans les marquer comme Sprint 0.

C'EST UTILE ? PARTAGEZ-LE