Planifier un sprint

Un sprint est un bloc de temps fixe à l’intérieur d’un projet : une date de début, une date de fin, et l’ensemble des tâches engagées dessus.

Les sprints sont optionnels. Si votre équipe tire du travail en continu depuis un tableau, vous pouvez sauter cette page entièrement. Utilisez les sprints quand vous voulez une conversation récurrente du type « à quoi s’est-on engagé, et est-ce qu’on y est arrivé ? ».

Ouvrez un sprint

Créez-le dans la section sprints du projet : donnez-lui un nom, une date de début et une date de fin. Deux semaines est la durée habituelle. Une semaine marche si votre travail est petit et régulier ; quatre semaines veut généralement dire que le plan est périmé à la fin.

Remplissez-le

Tirez du travail depuis le backlog. Depuis une vue en liste, vous pouvez sélectionner beaucoup de tâches d’un coup et les affecter toutes au sprint, ou survoler une tâche et appuyer sur C.

Deux habitudes font que le chiffre final veut dire quelque chose :

Estimez avant de vous engager, pas après. Une tâche non estimée compte pour zéro dans un graphique en points, donc un sprint plein de travail non estimé a l’air terminé avant d’avoir commencé.

Engagez-vous sur moins que ce que vous croyez. Les deux ou trois premiers sprints sont de la mesure, pas de la performance. Vous découvrez ce que votre équipe livre réellement en deux semaines. Ce chiffre est presque toujours plus bas que le plan, et le connaître est tout l’intérêt.

Pendant qu’il tourne

dotby écrit un instantané du sprint une fois par jour, chaque jour où il est ouvert. C’est ce qui dessine le graphique de burn-up : le périmètre engagé en une ligne, le travail terminé en une autre, qui grimpe vers elle.

L’instantané quotidien compte plus qu’il n’y paraît. Comme chaque jour est figé au moment où il arrive, le travail ajouté en cours de sprint reste visible comme une marche sur la ligne de périmètre, au lieu de réécrire l’histoire en silence. L’inflation du périmètre apparaît sous une forme que vous pouvez montrer du doigt en rétrospective.

Comment le lire :

• Terminé qui grimpe régulièrement vers le périmètre — sain.
• Périmètre qui grimpe aussi — vous prenez du travail neuf en cours de sprint. Parfois c’est juste, ça vaut toujours la peine de le nommer.
• Terminé à plat, puis une falaise à la fin — tout s’est fini le dernier jour, ce qui veut généralement dire que les tâches sont trop grosses pour avancer.

Clôturez-le

Terminez le sprint quand le bloc de temps se termine — pas quand le travail se termine. C’est cette distinction qui rend le chiffre honnête.

Le travail inachevé ne disparaît pas. Vous décidez, tâche par tâche, ce qui lui arrive : l’emporter dans le sprint suivant, ou le renvoyer au backlog. Quiconque suit une tâche qui finit un sprint inachevée en est averti, donc rien ne passe à la trappe.

Les sprints terminés restent là, avec leurs graphiques intacts. Cet historique est la meilleure matière de planification que vous aurez jamais — après trois sprints, vous arrêtez de deviner votre capacité et vous commencez à la lire.

Sprints, modules et initiatives

Trois façons différentes de regrouper le travail, faciles à confondre :

Regroupement	Répond à	Vit dans
Sprint	Quand — dans quel bloc de temps	Un projet
Module	Quelle partie — dans quel chantier	Un projet
Initiative	Vers quel résultat	Plusieurs projets

Une tâche peut être dans un sprint et dans un module en même temps. Ce sont des axes indépendants, pas concurrents.

Ensuite

• Projets et vues — enregistrez une vue « ce sprint » pour que l’équipe n’ait qu’un seul endroit où regarder.
• Concepts clés — comment les sprints se relient à tout le reste.