Dans le système que je présente sur ce blog, le sprint est souvent la dernière pierre de l’édifice. Pour bien comprendre son rôle, il est utile de connaître les autres briques : les inboxes capturent ce qui arrive, le calendrier accueille les contraintes temporelles et le Kanban permet de suivre les tâches. Le sprint donne ensuite un horizon commun à l’ensemble.

On peut bien sûr reprendre séparément certaines idées de ce système. Mais, à mon avis, le tout est plus utile que la somme des parties. Sans sprint, un Kanban risque de devenir une liste toujours plus longue. Sans inboxes, de nouvelles demandes s’ajoutent de façon désordonnée. Sans calendrier, les échéances et les rendez-vous se mélangent aux tâches que l’on peut choisir de réaliser à différents moments.

Le sprint cimente ces éléments en imposant une décision simple : sur quoi vais-je réellement chercher à avancer pendant les prochaines semaines ?

Un contrat avec soi-même

Le terme « sprint » vient du développement logiciel et des méthodes agiles. Je n’en reprends pas ici toutes les règles. Je conserve surtout une idée : au lieu de partir dans toutes les directions, on définit une temporalité, puis on choisit des objectifs raisonnables pour cette période.

Dans un système personnel, le sprint ressemble donc à un contrat passé avec soi-même. Au début, je sélectionne délibérément un certain nombre de tâches. Surtout, je décide que certaines autres n’en feront pas partie. Ce second choix est essentiel : un sprint n’a de valeur que s’il protège aussi contre la tentation de tout commencer à la fois.

Le contrat ne consiste pas nécessairement à terminer toutes les tâches sélectionnées. Certaines dépendent d’une autre personne, comportent beaucoup d’inconnues ou s’étendent naturellement sur plusieurs sprints. Je m’engage plutôt à avancer sur chacune d’elles.

Si une tâche est présente au début du sprint et que, plusieurs semaines plus tard, absolument rien n’a bougé, elle n’aurait probablement pas dû être retenue. Peut-être était-elle trop floue, pas assez importante, bloquée dès le départ ou simplement incompatible avec la charge du sprint. Ce n’est pas grave : cet écart fournit une information utile pour mieux choisir la prochaine fois.

Cette nuance évite deux excès. Le premier serait de remplir le sprint de petits sujets faciles uniquement pour pouvoir tout cocher. Le second serait d’y placer une quantité irréaliste de grands projets, puis de considérer le sprint comme un échec parce qu’ils ne sont pas tous achevés. L’objectif est de provoquer des progrès concrets, pas de construire un tableau de chasse.

Choisir la durée d’un sprint

La bonne durée dépend fortement du rythme de vie professionnel et personnel. Un sprint trop court entraîne des revues permanentes et laisse peu de temps aux tâches longues. Un sprint trop long réduit l’effet du contrat : il devient difficile d’anticiper sa disponibilité et la liste initiale perd progressivement son sens.

En ce qui me concerne, un sprint dure souvent autour d’un mois. Cette durée me laisse le temps de faire avancer des sujets variés sans repousser trop loin la prochaine occasion de remettre le système à plat. Ce n’est cependant pas une règle universelle. Une personne dont le travail change très vite pourra préférer une ou deux semaines ; quelqu’un qui organise surtout des projets personnels pourra choisir une période plus longue.

Le meilleur repère est la revue inter-sprints, sur laquelle on revient un peu plus bas. La durée doit être assez courte pour que cette revue permette de corriger régulièrement le système, mais assez longue pour que le sprint ait le temps de produire quelque chose. Il est aussi pratique de choisir un rythme prévisible, par exemple une revue à la fin de chaque mois, plutôt que de décider au dernier moment que le sprint est terminé.

Traiter les nouvelles tâches pendant le sprint

La temporalité du sprint change la façon de traiter ce qui arrive dans les inboxes. Lorsqu’un élément capturé pourrait devenir une nouvelle tâche, la première question est : cela peut-il attendre le prochain sprint ?

Si la réponse est oui, je place le sujet dans la colonne « Prochain sprint » du Kanban. Il ne disparaît pas et je n’ai pas besoin de trancher immédiatement tous ses détails. Je prends simplement rendez-vous avec lui pour la prochaine revue.

Cette règle protège le contrat initial. Sans elle, chaque idée intéressante et chaque demande récente peuvent sembler prioritaires. Le sprint finit alors par contenir beaucoup plus de tâches qu’au départ, tandis que les choix initiaux passent au second plan.

Si le sujet ne peut réellement pas attendre, je l’intègre au sprint. Les imprévus existent et le système doit rester assez souple pour les absorber. Il est néanmoins utile de distinguer les tâches présentes dès le début de celles qui sont entrées en cours de route. Idéalement, ces ajouts restent minoritaires. S’ils dominent régulièrement le sprint, il faut sans doute prévoir davantage de marge ou revoir la manière dont le travail est sélectionné.

Prenons un exemple simple : je reçois un avis d’impôt. Si la date limite de paiement tombe pendant le sprint actuel, la tâche rejoint immédiatement le Kanban. Si elle tombe plus tard et qu’aucune préparation urgente n’est nécessaire, je peux la placer dans « Prochain sprint ». Elle sera examinée au bon moment, sans encombrer le travail en cours.

Il ne s’agit pas d’appliquer cette règle de manière rigide. Une tâche très courte peut parfois être traitée immédiatement, et une urgence véritable doit évidemment passer avant le plan. L’important est que l’exception reste consciente. Ajouter une tâche au sprint doit être une décision, pas un réflexe.

La revue inter-sprints, pivot du système

Entre deux sprints, je consacre un vrai moment à la revue. Dans un monde idéal, il faut pouvoir y réserver au moins une demi-journée, au calme et sans distraction. Personnellement, j’essaie de bloquer une journée entière.

Cette durée peut sembler importante, mais la revue ne consiste pas seulement à déplacer quelques cartes. Elle permet de vérifier l’état réel du système, de prendre du recul et de décider ce qui mérite une place dans les semaines suivantes. Plus le Kanban contient de tâches et plus les sphères professionnelle et personnelle sont mêlées, plus ce temps devient précieux.

La revue se déroule en deux grandes parties : fermer proprement le sprint qui s’achève, puis ouvrir le suivant.

Première partie : fermer proprement le sprint

Je commence par les tâches de la colonne « À archiver ». Pour chacune, je vérifie que la DoD, la définition de « terminé », a bien été atteinte. Une tâche ne doit pas être classée comme terminée uniquement parce que sa partie principale est faite : les dernières actions prévues dans sa DoD comptent aussi.

« Clôturer » ne signifie pas supprimer. La tâche sort du Kanban actif, mais je conserve une trace de son contenu et du sprint pendant lequel elle a été achevée. Elle peut rejoindre un autre tableau comprenant une colonne par sprint terminé, une base d’archives ou une simple liste. La forme importe moins que la possibilité de retrouver ce qui a été accompli, car on y reviendra régulièrement, y compris juste après, lors de l’ouverture du sprint suivant, dont on parle un peu plus bas.

Je profite également de cette transition pour réaliser différentes tâches récurrentes : administration, ménage numérique, rangement ou autres opérations d’entretien. Leur nature dépend entièrement de la vie de chacun. C’est l’une des raisons pour lesquelles la durée du sprint et la date de la revue sont des choix personnels : le rituel doit s’intégrer à un rythme réaliste.

Je fais ensuite un point exhaustif sur toutes les tâches encore ouvertes. Je vérifie leur statut, leur DoD, leur prochaine action et les informations conservées dans leur description. Une tâche marquée « En attente » mérite peut-être une relance. Une autre peut être moins bloquée qu’il n’y paraît. Une troisième n’a peut-être plus aucune raison d’exister.

C’est donc aussi le moment d’abandonner certaines tâches. Le contrat du sprint n’oblige pas à conserver éternellement une idée devenue inutile. Supprimer consciemment un engagement obsolète est plus sain que le reporter de sprint en sprint sans jamais le remettre en question.

À la fin de cette première partie, le Kanban doit refléter la réalité. Les tâches terminées sont archivées, les tâches restantes sont propres et les sujets abandonnés ne créent plus de bruit.

Deuxième partie : ouvrir le sprint suivant

Pour ouvrir le nouveau sprint, le principe est de ne rien se refuser trop tôt. Je rassemble les idées, les obligations et les envies qui pourraient mériter une place. Je décide ensuite lesquelles exécuter immédiatement, lesquelles transformer en tâches bien structurées et lesquelles laisser de côté.

C’est précisément pour prendre ces décisions que la revue demande du temps. Une tâche ne doit pas entrer dans le sprint avec un titre vague et l’espoir que sa signification deviendra claire plus tard. Je peux réfléchir à sa DoD, à sa prochaine action, à son contexte et aux éventuelles dépendances. Je peux aussi constater qu’elle est trop large et la découper, ou au contraire que plusieurs petites cartes poursuivent le même résultat.

Je commence en priorité par la colonne « Prochain sprint ». Tous ses éléments ont été repoussés pour être examinés à cet instant précis. Chacun doit recevoir une décision : entrer dans le sprint, attendre encore, être reformulé ou être abandonné. La colonne ne doit pas devenir un débarras dont le contenu est automatiquement reconduit.

Je reparcours ensuite les tâches archivées lors des sprints précédents. Certaines peuvent révéler une action à renouveler ou un sujet qui revient régulièrement. La profondeur de cet historique dépend du temps disponible et de la durée des sprints. Quand je le peux, j’aime remonter jusqu’à un an en arrière : cela permet notamment de retrouver des obligations saisonnières auxquelles je n’aurais pas pensé spontanément.

Enfin, je consulte les modèles de tâches récurrentes.

Utiliser des modèles pour les tâches récurrentes

Une tâche récurrente ne doit pas nécessairement rester active en permanence. Je préfère conserver une liste de modèles, puis décider à chaque revue s’il est pertinent d’en créer une nouvelle instance pour le sprint à venir.

Ces modèles peuvent concerner, par exemple :

  • Les rendez-vous médicaux et les contrôles réguliers ;
  • L’entretien d’un véhicule ou du logement ;
  • La comptabilité professionnelle et personnelle ;
  • Les échéances administratives ou scolaires ;
  • La préparation de réunions récurrentes, comme un conseil de classe ou une Assemblée Générale associative.

Le modèle sert de rappel et de point de départ. Il peut déjà contenir une DoD, une liste d’étapes habituelles ou les documents utiles. La nouvelle tâche reste toutefois adaptable : l’entretien nécessaire ce mois-ci n’est pas forcément identique au précédent, et une démarche administrative peut avoir changé.

La revue permet aussi de faire évoluer cette bibliothèque. Si une tâche achevée a de fortes chances de revenir, je peux en faire un nouveau modèle. Si un modèle n’est plus pertinent, je le supprime. Comme le reste du système, cette liste doit rester vivante plutôt que s’accumuler indéfiniment.

Suivre quelques données sur ses sprints

Le suivi statistique est optionnel. Je conseille de commencer par faire fonctionner correctement les sprints et les revues avant de construire un tableau de bord. Des données précises sur un système mal tenu donnent surtout une impression trompeuse de contrôle.

Avec un peu d’expérience, quelques indicateurs simples peuvent néanmoins aider. Pour chaque sprint, je conserve :

  • Le nombre de tâches présentes au début du sprint ;
  • Le nombre de tâches restantes à la fin du sprint ;
  • Le nombre de tâches ajoutées en cours de sprint.

Pour ces trois catégories, je distingue les tâches professionnelles des tâches personnelles. Cette séparation me permet de repérer un déséquilibre sans avoir besoin de maintenir deux systèmes complètement indépendants.

Ces chiffres ne sont pas une note. Une tâche peut représenter cinq minutes de travail ou plusieurs semaines ; compter les cartes ne mesure donc ni l’effort ni la valeur produite. En revanche, les tendances sont instructives. Si beaucoup de tâches entrent systématiquement en cours de sprint, le contrat initial ne correspond peut-être pas à la réalité. Si de nombreuses tâches restent ouvertes sans avoir avancé, le sprint est peut-être trop chargé ou mal préparé.

J’ajoute volontiers un court bilan qualitatif : ce qui s’est bien passé, ce qui s’est mal passé, ce qui aurait pu être mieux fait et les tâches majeures qui ont eu un véritable impact. Quelques phrases suffisent. L’objectif est de conserver les enseignements qui aideront à préparer le sprint suivant, pas de rédiger un rapport détaillé sur chaque journée.

Un cadre pour mieux choisir

Le sprint n’est pas une couche de planification supplémentaire destinée à remplir le calendrier. C’est un cadre pour faire des choix. Il oblige à limiter volontairement le nombre de sujets sur lesquels on cherche à avancer, puis crée un moment régulier pour remettre ces choix en question.

Sa valeur vient autant de ce qui reste dehors que de ce qui entre. La colonne « Prochain sprint » permet d’accueillir une idée sans casser le contrat en cours. La revue inter-sprints garantit ensuite que cette idée sera réellement examinée, plutôt qu’oubliée dans une liste sans fin.

Lorsque ce rythme fonctionne, le système devient plus fiable. Les inboxes continuent d’absorber les nouveaux éléments, le Kanban décrit honnêtement l’état des tâches et le calendrier protège les contraintes de temps. Le sprint relie le tout en donnant une direction temporaire, assez ferme pour guider les décisions et assez souple pour apprendre de la réalité.