ClickUp Sprints : comment j’ai structure notre workflow agile pour 8 developpeurs
Apres avoir teste Jira (trop lourd), Linear (trop minimaliste), et diverses combinaisons Notion + Trello, j’ai finalement standardise notre équipe dev de 8 personnes sur ClickUp Sprints. 18 mois plus tard, notre velocite a augmente de 30%, nos sprints sont livres a 85% (vs 60% avant), et l’overhead de gestion a été divise par 2. Voici la configuration complète.
Ce guide s’adresse aux équipes dev de 3 a 20 personnes qui veulent pratiquer Scrum ou Kanban agile sans la complexite de Jira.
📋 Découvrez les meilleurs outils de gestion de projet
Comparez ClickUp, Monday.com, Asana et Notion pour trouver l’outil idéal pour votre équipe en 2026.
Voir le comparatif 2026 →Prerequis et plan recommande
Les Sprints ClickUp sont disponibles sur le plan Business (12 euros/membre/mois). Le plan Unlimited permet des sprints de base, mais les automatisations de sprint (cloture, report de taches non terminées) nécessitént Business.
Structure de l’espace Developpement
- Espace : Produit [Nom App]
- Dossier : Roadmap et Vision
- Dossier : Backlog
- Dossier : Sprints (Sprint 1, Sprint 2, etc.)
- Dossier : Bugs
- Dossier : Tech Debt
- Dossier : Docs Techniques
Configuration du Backlog produit
User Stories et champs personnalisés
- Type (User Story / Bug / Task / Epic)
- Epic parente
- Story Points (champ numerique 1-13, suite de Fibonacci)
- Priorite (Must Have / Should Have / Could Have / Won’t Have)
- Complexite (S / M / L / XL)
- Composant technique (Frontend / Backend / API / Infrastructure / Mobile)
- Criteres d’acceptation (champ texte long)
- Sprint assigne (une fois planifie)
Estimation et grooming
Notre session de grooming bi-hebdomadaire (1h) se fait directement dans ClickUp en vue List. L’équipe vote sur les story points via des commentaires — pas de plugin de planning poker separe. Chaque dev @mentionne sa valeur dans les commentaires, le Product Owner calcule la médiane et l’affecte. Simple et efficace.
Creer et configurer un Sprint dans ClickUp
Dans le dossier Sprints, creez une nouvelle liste et activez Sprint dans les parametrès. Configurez : duree du sprint (2 semaines recommandées), date de debut / fin automatique, velocite cible (en story points, calculee sur les 3 derniers sprints).
Sprint Planning : sélection des taches
Depuis le Backlog, glissez-deposez les taches dans le Sprint courant jusqu’a atteindre la velocite cible. ClickUp affiche la somme des story points en temps réel pendant le planning — vous savez exactement quand vous étés au-dela de la capacité.
Workflows et statuts du Sprint
- Backlog Sprint — dans le sprint, pas encore commence
- In Progress — developpement en cours
- In Review — PR ouverte, en attente de code review
- QA — en test
- Done — validé et merge
- Blocked — dependance externe bloquante
Rituels agile dans ClickUp
Daily Standup asynchrone
J’ai remplace le standup quotidien synchrone par un systeme asynchrone dans ClickUp : chaque matin a 9h, chaque dev met a jour le statut de ses taches en cours. En 15 minutes, le Scrum Master scanne la vue Workload pour détécter les blocages. Seuls les blocages réels declénchent une reunion. Resultat : 45 minutes de reunion quotidienne economisees x 8 devs = 6h de developpement réel reçuperees par jour.
Sprint Review (demo)
La vue List filtree sur statut Done du sprint donne directement la liste des fonctionnalites livrables. Le Product Owner utilise cette vue pour preparer la demo client. Fini la préparation manuelle du bilan de livraison.
Retrospective
J’ai cree un template de doc ClickUp Retrospective Sprint avec les sections : ce qui a bien fonctionne, ce qui n’a pas fonctionne, actions d’amélioration (avec assigne et date), velocite réelle vs cible. Les actions d’amélioration sont converties en taches Tech Debt assignées dans le sprint suivant.
Intégration GitHub / GitLab
Via l’integration ClickUp-GitHub, chaque PR associee a une tache ClickUp met a jour automatiquement le statut de là tache : PR ouverte = In Review, PR mergee = Done. Zero mise a jour manuelle des statuts pour les devs. Notre guide d’integration GitHub est détaillé ici : ClickUp integrations GitHub.
Gestion des bugs
Les bugs ont leur propre liste avec des statuts dedies et sont estimes en story points comme les US. Chaque sprint inclut un budget bugs de 20% de la velocite réservé pour les correctifs urgents. Ce buffer evite les sprints sabotes par des bugs imprévus. Pour les comparaisons avec d’autrès outils agile, voir ClickUp vs Jira.
Migration depuis Jira
Si vous migrez depuis Jira, notre guide ClickUp remplacer Jira couvre les specificites de la migration. Points d’attention : l’import des epics, la preservation des story points, et la migration du backlog.
Resultats après 18 mois
- Velocite moyenne : +30% (de 38 a 52 story points/sprint)
- Taux de completion sprint : de 60% a 85%
- Temps de reunion agile : de 5h a 2.5h/semaine par dev
- Bugs en production : -45% (meilleure visibilite sur la QA)
- Economie vs Jira : 1 440 euros/an pour 8 devs
Velocity tracking et prévision de capacité
Analyser la vélocité sur les 6 derniers sprints
La vélocité (nombre de story points complétés par sprint) est l’indicateur clé pour planifier de façon réaliste. J’ai créé un doc ClickUp « Vélocité Historique » mis à jour après chaque sprint :
- Sprint N : vélocité cible / vélocité réelle / delta
- Raisons du delta (vacances, incidents production, scope creep)
- Vélocité moyenne sur 6 sprints (indicateur de planification)
Sur la base de cette vélocité moyenne (52 points/sprint chez nous), on peut maintenant dire avec 80% de fiabilité quand’une feature sera livrée. Fini les estimations à la louche qui faisaient souffrir les relations avec le Product Owner et le business.
Capacité ajustée par sprint
La capacité d’un sprint ne doit pas être constante. Vacances, conférences, jours fériés, interviews de recrutement — tout ça réduit la capacité réelle. J’ai configuré dans ClickUp un champ « Capacité ajustée » par sprint, calculé en heures disponibles de l’équipe × facteur de focus (généralement 0.7 pour tenir compte des interruptions). Le sprint planning ne commence jamais sans avoir calculé cette capacité réelle. Résultat : les sprints sous-chargés par manque de calcul ont disparu, et les sprints surchargés ont été réduits de 60%.
ClickUp pour le Kanban continu : alternative aux Sprints
Les sprints ne conviennent pas à toutes les équipes. Pour les équipes de maintenance ou de support technique qui ont un flux continu de tickets sans cadence fixe, le Kanban continu dans ClickUp est plus adapté. Configuration :
- Pas de liste Sprint, juste une liste Backlog avec WIP limits (Work In Progress) par colonne
- Règle de WIP : maximum 3 tâches « In Progress » par développeur
- Métriques Kanban : temps de cyclé (Cyclé Time), Lead Time par type de tâche
Notre guide ClickUp Kanban guide détaille cette configuration pour les équipes qui préfèrent le flux continu aux cadences fixes.
Comment j’ai structuré nos sprints agile avec ClickUp pour une équipe de cinq développeurs
J’ai mis en place ClickUp pour la gestion agile de notre équipe de développement il y a deux ans. Avant, on utilisait Jira avec un sentiment de complexité disproportionné pour notre taille. ClickUp a changé notre façon de travailler de façon durable. Voici la configuration exacte que j’utilise et les leçons apprises en chemin.
Architecture de notre espace ClickUp pour le développement agile
| Niveau | Utilisation | Exemple concret |
|---|---|---|
| Workspace | Entreprise entière | Nom de l’entreprise |
| Space | Département ou produit | Produit Principal et Marketing et Ops |
| Folder | Projet ou epic | Sprint Q2 2026 et Module Facturation |
| List | Backlog ou sprint actif | Backlog et Sprint 1 et Sprint 2 |
| Task | User story ou bug | En tant qu’utilisateur je veux… |
| Subtask | Tâches techniques | Créer endpoint API et Écrire les tests |
Ma configuration des Custom Fields pour le suivi agile
Dans chaque tâche de sprint, j’utilise ces champs personnalisés : Story Points avec valeurs de la suite de Fibonacci 1 3 5 8 13, Type avec options Story Bug Tech Debt Spike, Sprint avec liste des sprints en cours et futurs, Priorité avec les niveaux Bloquant Critique Haute Normale Basse, et Reviewer pour l’assignation de la revue de code.
Notre rituel de sprint en cinq cérémonies
Sprint Planning le lundi matin de 9h à 11h : on importe les stories du backlog vers le sprint actif en s’appuyant sur la vue Gantt pour visualiser les dépendances. Sprint Review le vendredi après-midi de 16h à 17h : on fait le tour des tâches terminées en Kanban, chaque développeur présente sa contribution. Retrospective le vendredi à 17h : 30 minutes, trois questions structurées en champs personnalisés ClickUp. Daily Standup chaque matin à 9h30 pour dix minutes : on lit ensemble le Kanban filtrée sur les tâches In Progress. Backlog Refinement le mercredi de 14h à 15h30 : on’estime et on priorise les prochaines stories.
Le Kanban que j’ai paramétré pour notre équipe
| Colonne statut | Définition | Limite WIP |
|---|---|---|
| Backlog Sprint | Prêt à démarrer dans le sprint | Illimité |
| In Progress | En cours de développement | 2 par développeur |
| Code Review | Pull request ouverte | 3 au total |
| QA | En test par le QA | 2 au total |
| Done | Livré et validé | Illimité |
La limite WIP de deux tâches par développeur en In Progress est la règle qui a le plus changé notre façon de travailler. Avant, chacun avait cinq à six tâches en cours simultanément et rien ne se terminait vraiment. Depuis la mise en place de cette limite, notre cyclé time moyen a diminué de 40 pourcent.
Intégrations que j’utilise avec ClickUp pour le développement
| Intégration | Usage | Valeur ajoutée |
|---|---|---|
| GitHub | Lier les PR aux tâches ClickUp | Traçabilité code et tâche |
| Slack | Notifications changements de statut | Pas besoin de vérifier ClickUp manuellement |
| Figma | Lier maquettes aux stories | Design et dev sur la même tâche |
| Sentry | Créer tâche depuis une erreur | Bug tracké automatiquement depuis la prod |
Les métriques de sprint que je suis dans ClickUp
Je suis quatre métriques par sprint : le Velocity en story points terminés versus planifiés, le Cyclé Time en jours entre In Progress et Done, le Bug Rate en nombre de bugs du sprint précédent remontés en production, et le Carry-over Rate en pourcentage de stories non terminées reportées au sprint suivant. Ces données sont disponibles nativement dans la vue Workload et les rapports de sprint de ClickUp.
Questions fréquentes sur ClickUp pour les sprints agile
ClickUp peut-il vraiment remplacer Jira pour une équipe de développement ?
Pour les équipes de moins de vingt développeurs, oui. ClickUp gère les sprints, les backlogs, les story points, les burn-down charts et les intégrations GitHub et GitLab. L’avantage sur Jira : toute l’équipe, y compris les profils non-techniques, utilise le même outil sans interface complexe. Pour les grandes organisations avec Confluence et des besoins de compliance spécifiques, Jira reste plus adapté.
Comment gérer plusieurs équipes Scrum sur le même ClickUp ?
Je recommande un Space par équipe avec un Folder par sprint. Les dépendances inter-équipes se gèrent via les liens de tâches ClickUp et la vue Timeline multi-spaces. Pour une organisation avec trois équipes Scrum et plus, il vaut mieux payer le plan Business qui débloque les permissions granulaires par Space.
Les burn-down charts de ClickUp sont-ils précis ?
Oui, à condition que les story points soient correctement renseignés sur chaque tâche et que les statuts soient mis à jour quotidiennement. J’ai constaté que les burn-down charts ClickUp sont fiables à plus de 90 pourcent quand l’équipe respecté la discipline de mise à jour. La configuration initiale prend deux heures mais l’automatisation du reporting en vaut la peine.
Quel est le coût de ClickUp pour une équipe de cinq développeurs ?
Le plan Unlimited à sept euros par utilisateur par mois, soit trente-cinq euros par mois pour cinq personnes ou quatre cent vingt euros par an, couvre tous les besoins d’une équipe Scrum de cette taille : sprints natifs, intégrations Git, automatisations de base et vues multiples. Pour des automatisations avancées et les tableaux de bord d’équipe, le plan Business à douze euros par utilisateur devient nécessaire.
A lire aussi
