J’ai écris récemment un article au sujet de solutions alternatives à la numérotation usuelle des sprints. Dans cet article, je voudrais parler d’un numéro très spécial que certaines équipes utilisent pour numéroter leurs sprints – le zéro.

Le concept de “sprint zéro” est devenu populaire au sein de certaines équipes et il est donc important de voir s’il s’agit ou non d’une bonne idée.

Tout d’abord, mettons-nous d’accord sur le postulat de départ de “sprint zéro”. Les partisans du sprint zéro proclament qu’il est nécessaire parce qu’il y a des choses qui doivent être faites avant qu’un projet Scrum puisse démarrer. Par exemple, la création d’une équipe. Cela peut vouloir dire embaucher ou affecter des personnes d’un projet à un autre. Quelques fois, il y a du matériel à acheter ou du moins à mettre en place. Beaucoup de projets argumentent sur le besoin d’écrire un product backlog initial (même si c’est seulement à un niveau macro) lors d’un sprint zéro.

Un des plus gros problèmes avec le fait d’avoir un sprint zéro est que cela créé un précédent qu’il existe certains sprints ou certains types de sprints ayant des règles spécifiques. Les équipes faisant un sprint zéro se dispenseront, par exemple, de l’idée d’avoir quelque chose de potentiellement livrable à la fin de ce sprint. Comment peuvent-ils avoir quelque chose de potentiellement livrable après tout si l’objectif du sprint est de réunir une équipe qui aura la charge de développer le produit ?

Je trouve que certaines choses utilisées comme argument en faveur du besoin d’avoir un sprint zéro devraient être considérés vraiment comme des choses qui devraient apparaître dans ce que j’appelle un projet avant le projet1. Avant qu’un projet de développement débute, il y a souvent un projet pour décider s’il devrait y avoir un projet de développement. Avant qu’une entreprise ne lance une nouvelle initiative majeure, quelqu’un doit réfléchir si cette initiative devrait être menée ou pas.

La prise de cette décision peut elle-même être considérée comme un projet.

Etant donné que Scrum fonctionne comme un cadre de travail de gestion de projet générique, il peut être utilisé pour gérer le travail de ce projet-avant-le-projet. Pendant ce projet-avant-le-projet, les membres de cette équipe (voire peut être seulement le futur product owner) peuvent travailler pour créer un product backlog initial, trouver ou embaucher des équipiers, mettre en place un environnement technique, et ainsi de suite.

Je pense qu’il est intéressant d’envisager ce travail comme étant un projet à part entière car il n’est pas difficile d’imaginer sans aller bien loin que ce travail prendra plus d’un sprint, le sprint zéro spécial. Comment une équipe qui utilise un sprint zéro peut elle appeler son second sprint si elle en a besoin d’un de plus pour faire n’importe quel travail qui justifierait ce type de sprint spécial ? Un sprint 0,5 ?

Quelques précautions sont nécessaires désormais :

  • Faites en sorte que tout “projet avant le projet” soit mené de manière aussi légère que possible. La plupart des projets de développement ne nécessitent pas généralement de projet avant de pouvoir commencer.
  • Rester fidèle aux principes de Scrum. Une équipe participant à un projet avant le projet ne sera peut être pas capable d’avoir quoi que ce soit de potentiellement livrable. C’est tout à fait correct. Mais essayez de comprendre pourquoi avoir quelque chose de potentiellement livrable est un principe fondamental de Scrum et appliquez-le honnêtement au projet avant le projet.

Ce dernier point – rester fidèle aux principes de Scrum dans un projet-avant-le-projet– sera approfondit dans mon prochain article.


Auteur : Mike Cohn
Source : Sprint Zero: A Good Idea or Not?
Date de parution originale : 26 Février 2013


Traducteur : Nicolas Mereaux
Date de traduction : 17/01/2017


Copyright ©1998-2016 Mountain Goat Software. All Rights Reserved.


  1. l’auteur n’a pas employé de terme anglo-saxon pour avant-projet (comme preliminary draft ou pre-project ou preliminary project) mais bien l’expression “projet before the project” d’où la traduction en français de “projet avant le projet” - NdT