La planification de Sprint a toujours reposé sur une hypothèse discrète : la capacité, c'est le nombre de personnes multiplié par la time box. On estime le travail, on le compare à ce que l'équipe a terminé lors du cycle précédent, et on s'engage sur un périmètre qui tient.
Faites entrer des Agents de codage IA dans l'équipe et l'équation cesse de décrire la réalité. Un Agent peut prendre une Task dès qu'elle est prête, travailler en parallèle de tous les autres Agents et revenir avec un diff et des résultats de tests avant le standup où vous comptiez en parler. La capacité d'exécution gonfle de façon spectaculaire. La réaction tentante consiste à s'engager sur davantage de périmètre, et les équipes qui cèdent à cette tentation découvrent en général le mode de défaillance avant la fin du premier cycle : le Sprint se clôture avec beaucoup de code terminé et un mur de modifications non relues que personne n'a eu le temps d'accepter.
Voilà la thèse défendue ici : avec des Agents dans l'équipe, l'exécution cesse d'être la contrainte du Sprint, et la revue humaine devient cette contrainte. Planifiez en fonction du débit d'acceptation, et non de la quantité de code que l'on peut produire. Nous prendrons les Sprints de Sharkly comme mécanisme concret, en séparant clairement l'argument de planification des faits produit.
TL;DR
Un Sprint dans Sharkly est un ensemble de Tasks limité dans le temps, rattaché à un seul Space ; les Tasks restent la source d'exécution et de discussion, tandis que le Sprint ajoute le calendrier, le périmètre et le reporting. Les Sprints sont optionnels et fonctionnent selon l'un de deux modes : la cadence automatique, où Sharkly tient le calendrier et reporte le travail inachevé, ou le mode Manuel, où les personnes créent, démarrent et clôturent les Sprints explicitement. Le reporting couvre le périmètre, le travail démarré et terminé, le taux d'achèvement, la capacité et l'historique de burnup. Pour les équipes hybrides humains-Agents, le changement de planification est le suivant : les Agents gonflent la capacité d'exécution, mais l'acceptation reste du ressort des personnes. L'engagement honnête d'un Sprint est donc borné par la quantité de travail terminé que vos relecteurs peuvent accepter, et non par ce que vos Agents peuvent produire.
Ce qu'est un Sprint dans Sharkly
Un Sprint est un ensemble de Tasks limité dans le temps, rattaché à un seul Space. Il aide une équipe à planifier un périmètre ciblé, à suivre sa progression et à décider du sort du travail inachevé à la fin de la time box. Les Tasks restent la source d'exécution et de discussion ; un Sprint ajoute par-dessus le calendrier, le périmètre et le reporting.
La documentation emploie le terme Sprint, avec le sens que l'industrie lui donne. Le Scrum Guide décrit les Sprints comme des conteneurs de durée fixe où les idées se transforment en valeur, et la version de Sharkly conserve cette filiation. Ce que Sharkly change, c'est qui exécute à l'intérieur de la fenêtre.
Trois limites gardent le concept limpide :
- Un Sprint appartient à un seul Space. Placer une Task dans un Sprint ne change pas son propriétaire.
- Les Sprints sont optionnels et s'activent par Space. Un Space qui raisonne en flux continu peut tout à fait ne jamais les activer.
- Un Sprint n'est ni un Project ni une View. Utilisez un Sprint quand la question est de savoir ce qui doit être terminé dans une time box donnée. Utilisez un Project pour un résultat qui peut s'étaler sur plusieurs Sprints ou Spaces. Utilisez une View pour une manière enregistrée d'inspecter les Tasks.
Cette dernière distinction joue un vrai rôle dans une équipe hybride : le Project porte le résultat, le Sprint porte l'engagement à court terme, et les Views portent les découpages dont chacun a besoin au quotidien.
Cadence automatique ou mode Manuel
Lorsque vous activez les Sprints pour un Space, vous choisissez l'un des deux modes de cycle de vie. Ce choix modifie le comportement du cycle de vie, pas le propriétaire des Tasks.
La cadence automatique confie le calendrier à Sharkly. Vous configurez la durée des Sprints, un cooldown facultatif, le jour de démarrage dans la semaine, le nombre de Sprints futurs à maintenir, le fuseau horaire, ainsi que des règles qui ajoutent automatiquement des Tasks lorsqu'elles entrent dans certaines catégories de statut. Sharkly crée alors les Sprints futurs, les démarre et les clôture selon le calendrier, et reporte le travail inachevé. Démarrer un Sprint à venir par anticipation clôture d'abord le Sprint en cours et reporte son travail inachevé dans le Sprint que l'on démarre.
Le mode Manuel laisse le contrôle du cycle de vie à l'équipe. Les personnes créent des Sprints planifiés selon les besoins, les démarrent sans modifier les dates configurées, font tourner plusieurs Sprints actifs en parallèle et choisissent où vont les Tasks inachevées à la clôture. La création automatique, le report, le cooldown et les règles d'ajout basées sur le statut restent inactifs en mode Manuel.
| Cadence automatique | Mode Manuel | |
|---|---|---|
| Calendrier | Sharkly crée, démarre et clôture les Sprints selon un rythme configuré | Les personnes créent, démarrent et clôturent les Sprints explicitement |
| Travail inachevé | Reporté automatiquement dans le Sprint suivant | Aiguillé à la clôture : aucun Sprint, un autre Sprint, ou un nouveau Sprint |
| Sprints actifs en parallèle | Un Sprint en cours par cadence | Plusieurs Sprints actifs autorisés |
| Entrée des Tasks | Des règles par catégorie de statut peuvent ajouter des Tasks pendant la fenêtre | Tasks ajoutées par les personnes via la planification, les listes ou le champ Sprint |
| Idéal pour | Une cadence régulière que l'équipe veut maintenir sans cérémonie | Des cycles irréguliers, des fenêtres pilotées par les releases ou des efforts qui se chevauchent |
Le vrai dilemme, posé honnêtement : adoptez la cadence automatique quand votre équipe suit un rythme régulier et souhaite que la mécanique soit maintenue à sa place. Choisissez le mode Manuel quand vos cycles sont irréguliers, quand ce sont les releases plutôt que le calendrier qui définissent vos fenêtres, ou quand vous avez besoin de deux Sprints actifs en même temps. Passer en mode Manuel conserve les Sprints existants mais arrête la planification automatique. Désactiver entièrement les Sprints clôture les Sprints actifs, supprime les Sprints futurs et conserve les données terminées pour le reporting.
Comment les Tasks entrent dans les Sprints, en sortent ou n'y figurent jamais
Les Sprints apparaissent dans cinq états d'affichage : Current, Upcoming, Planned, Completed et Canceled. Les Sprints terminés et annulés basculent dans l'archive du Space plutôt que d'encombrer la liste de planification active.
Vous ajoutez ou déplacez une Task via son champ Sprint, depuis une liste de Tasks ou pendant la planification de Sprint. Deux règles comptent plus qu'elles n'en ont l'air.
Premièrement, une Task peut n'être rattachée à aucun Sprint. C'est l'emplacement naturel du travail de Backlog et des Tasks qui ne sont engagées dans aucune time box.
Deuxièmement, ajouter une Task à un Sprint ne change pas son statut. C'est la règle que les équipes hybrides doivent intégrer, car dans Sharkly la catégorie de statut Backlog est un état de stationnement : créer une Task ou assigner un Agent tant que la Task reste en Backlog ne déclenche pas l'exécution. C'est en sortant la Task du Backlog vers un statut prêt que l'Agent assigné peut démarrer. La planification de Sprint et le lancement de l'exécution sont donc deux leviers distincts. Vous pouvez planifier tout le Sprint le lundi, avec les Agents déjà assignés, et rien ne se lance tant que chaque Task n'est pas délibérément déplacée vers un statut prêt. Les Automations de changement de statut peuvent ensuite prendre en charge les transitions que vous souhaitez standardiser.
Une dernière règle protège votre historique : seules les Tasks terminées peuvent être ajoutées à un Sprint précédent. Cela autorise des corrections historiques sans jamais placer de travail inachevé dans une période close.
Côté dates, le début et la fin d'un Sprint planifié sont modifiables, tandis que le début d'un Sprint actif est figé, mais sa fin peut être changée.
Ce que le reporting de Sprint vous apprend
Le reporting de Sprint inclut le nombre de Tasks et, lorsque les estimations sont activées sur le Space, les totaux en points d'estimation selon six lectures : périmètre, travail démarré, travail terminé, taux d'achèvement, capacité et historique de burnup.
La capacité mérite un examen attentif, car c'est le chiffre sur lequel s'ancrent les conversations de planification. Sharkly la dérive de la vélocité des Sprints récemment terminés lorsqu'il existe suffisamment d'historique, et se rabat sinon sur une estimation fondée sur la taille du Space. La documentation recommande de la traiter comme une donnée d'entrée de planification plutôt qu'une garantie, et pour une équipe hybride cette mise en garde n'est pas une clause de style : une vélocité mesurée sur une cohorte uniquement humaine cesse de prédire quoi que ce soit la semaine où vous ajoutez trois Agents. L'historique de burnup est souvent plus révélateur. Si le périmètre se termine en une poussée précoce puis que la courbe s'aplatit, c'est que vos Agents ont fini d'exécuter et que vos relecteurs ont passé le reste du Sprint à rattraper leur retard.
La contrainte de l'équipe hybride : planifier pour la revue, pas pour l'exécution
Tout ce qui suit relève d'un argument de planification, pas d'une fonctionnalité produit. Sharkly vous fournit la mécanique de Sprint décrite plus haut ; la façon de remplir le Sprint relève du jugement.
Partons de la répartition des rôles. Les Agents font la recherche, exécutent, testent et rendent compte. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat. Dans le codage agentique, tout ce qui se situe entre la direction et l'acceptation peut être délégué, mais l'acceptation reste humaine. Un Agent qui termine une Task ne l'a terminée dans aucun des sens que votre Sprint devrait compter : le diff, les résultats de vérification et les limites connues reviennent dans la Task, et une personne doit encore les lire et accepter, demander des modifications ou décider de la fusion.
Passons à l'arithmétique. Imaginons une équipe de cinq personnes qui ajoute des Agents et dont le débit d'exécution triple. Le débit de revue n'a pas triplé, lui : les cinq mêmes personnes le portent, et chaque changement accepté coûte une attention bien réelle. Planifiez le Sprint en fonction de la capacité d'exécution et l'excédent ne se transforme pas en valeur livrée. Il devient une file de travail non relu, et un changement non relu est du stock, pas de l'avancement. Pire, un Sprint qui se clôture pousse les relecteurs vers exactement le raccourci qui rend le développement à forte composante agentique dangereux : accepter du code sans le lire.
Retournez donc la question de planification. Au lieu de demander combien de travail l'équipe peut exécuter en deux semaines, demandez combien de travail d'Agent terminé vos personnes peuvent accepter en deux semaines. En pratique, cela change quatre habitudes :
- Estimer le coût de revue, pas seulement le coût de production. Une Task triviale à exécuter pour un Agent peut rester coûteuse à accepter.
- Plafonner le travail terminé mais non accepté en parallèle. Décidez combien de Tasks chaque relecteur peut réellement accepter par Sprint et arrêtez la planification au-delà de la somme. Il s'agit d'un accord d'équipe plutôt que d'un paramètre Sharkly, mais les métriques d'achèvement vous diront quand vous avez dépassé la limite.
- Lancer l'exécution de manière délibérée. Comme le Backlog met l'exécution en attente, vous pouvez échelonner les démarrages pour que le travail terminé arrive à un rythme que les relecteurs peuvent absorber, au lieu de tout recevoir d'un coup le deuxième jour.
- Lire le taux d'achèvement comme un indicateur de revue. Quand la courbe de burnup s'aplatit alors que les Agents tournent au ralenti, la contrainte s'est signalée d'elle-même. C'est le signe qu'il faut ajouter des relecteurs ou s'engager sur moins de travail, pas ajouter des Agents.
Rien de tout cela ne ralentit les Agents. Cela les oriente. Un Sprint planifié autour du débit d'acceptation livre tout ce sur quoi il s'engage, et ne demande jamais à quelqu'un d'approuver du code qu'il n'a pas eu le temps de lire.
Planifier un Sprint hybride, étape par étape
- Activez les Sprints pour le Space et choisissez un mode. Un rythme d'équipe régulier suggère la cadence automatique ; un travail piloté par les releases suggère le mode Manuel.
- Façonnez le périmètre. Faites glisser les Tasks candidates dans le Sprint à venir via la planification de Sprint ou le champ Sprint. Laissez le travail non engagé sans Sprint.
- Assignez les deux moitiés de chaque Task. Sharkly sépare la responsabilité humaine de l'exécution par l'Agent : les personnes vont dans l'ensemble des assignés, et un Agent ou une Crew occupe l'unique emplacement d'exécution. Modifier l'un ne change jamais l'autre.
- Rédigez des Tasks sur lesquelles un Agent peut agir. La description doit contenir l'objectif, les contraintes et les critères d'acceptation dont une nouvelle personne ou un Agent aurait besoin pour avancer.
- Lancez le travail au rythme de la revue. Sortez les Tasks du Backlog à mesure que la capacité de revue se libère.
- Clôturez avec intention. En mode Manuel, choisissez où va chaque Task inachevée. En cadence automatique, vérifiez ce qui a été reporté et demandez-vous si le périmètre était trop large ou la revue trop lente.
La discipline plus large consistant à travailler ainsi est traitée dans notre article pilier sur la gestion de projet avec agents IA ; le Sprint en est la tranche limitée dans le temps.
Si vos Sprints vivent aujourd'hui dans Jira
Vous n'avez pas besoin de reconstruire votre processus pour tester tout cela. L'intégration Jira de Sharkly peut importer les données de Sprint Jira et, lorsque l'import de Sprint est activé, le Space cible peut basculer en mode Jira Sprint : la cadence que votre équipe applique déjà est ainsi reprise, au lieu de partir de zéro. Le tutoriel sur l'assignation d'un ticket Jira à un Agent IA illustre la même idée à l'échelle d'un seul ticket, et la documentation Sharkly couvre en détail la configuration des Sprints et l'intégration Jira.
Commencez plus petit qu'une migration : activez les Sprints dans un seul Space, planifiez une fenêtre de deux semaines en fonction de la capacité d'acceptation réelle de vos relecteurs, et comparez le burnup avec votre dernier cycle 100 % humain.
FAQ
Suis-je obligé d'utiliser les Sprints dans Sharkly ?
Non. Les Sprints sont optionnels et s'activent par Space. Un Space qui préfère le flux continu peut les laisser entièrement désactivés, et même avec les Sprints activés, une Task peut n'être rattachée à aucun Sprint, ce qui est l'état normal du travail de Backlog.
Que deviennent les Tasks inachevées à la fin d'un Sprint ?
En cadence automatique, Sharkly clôture le Sprint selon le calendrier et reporte le travail inachevé dans le suivant. En mode Manuel, le flux de clôture vous demande où doivent aller les Tasks inachevées : vers aucun Sprint, vers un autre Sprint actif ou à venir, ou vers un Sprint nouvellement créé.
Les Agents peuvent-ils travailler automatiquement sur les Tasks d'un Sprint ?
Un Agent ou une Crew défini comme assigné d'exécution d'une Task peut réaliser le travail, mais l'appartenance à un Sprint ne déclenche jamais rien à elle seule. Le Backlog est un état de stationnement : assigner un Agent à une Task en Backlog ne lance pas l'exécution ; c'est le passage de la Task à un statut prêt qui peut démarrer le run. Cette séparation vous permet de planifier d'abord un Sprint entier, puis de libérer l'exécution au rythme que vos relecteurs peuvent absorber.
Comment Sharkly calcule-t-il la capacité d'un Sprint ?
La capacité s'appuie sur la vélocité des Sprints récemment terminés lorsqu'il existe suffisamment d'historique, et se rabat sinon sur une estimation fondée sur la taille du Space. La documentation conseille de la traiter comme une donnée d'entrée de planification plutôt qu'une garantie, ce qui compte doublement pour les équipes hybrides, où la vélocité mesure l'ensemble du système et non le goulot d'étranglement de la revue qu'il contient.
Puis-je ajouter une Task à un Sprint déjà terminé ?
Seules les Tasks terminées peuvent être ajoutées à un Sprint précédent. Cela permet des corrections historiques, comme créditer un travail terminé dans la fenêtre mais jamais enregistré, sans jamais placer de travail inachevé dans une période close.
