Définissez et planifiez efficacement votre Sprint

Vous avez maintenant un Product Backlog clair et priorisé.
Il est temps de passer à l’action : transformer ce backlog en Sprints concrets, avec des objectifs atteignables et un suivi efficace.
C’est ce qu’on appelle le Sprint Backlog : l’outil de pilotage quotidien de l’équipe.

Le Sprint Backlog contient :

1. L’objectif du Sprint (Pourquoi ?)

2. Les User Stories sélectionnées (Quoi ?)

3. Le plan en tâches concrètes (Comment ?)

1. L’objectif du Sprint (le pourquoi ?)

Un Sprint sans objectif clair, c’est comme une équipe de football qui entre sur le terrain sans savoir si elle doit gagner, s’entraîner ou faire le show : chaque joueur agit différemment, et l’équipe perd toute cohésion.

En Scrum, l’absence d’objectif de Sprint entraîne plusieurs risques :

• Le contexte n’est pas clair et donc il est difficile de prioriser les actions.

• Les membres travaillent sur des tâches déconnectées.

• On ne peut pas mesurer si le Sprint est réussi.

• Le client ou l’utilisateur final ne comprend pas la valeur livrée.

L’objectif de Sprint est donc la boussole de l’équipe : une phrase courte qui décrit la valeur métier livrée en fin de Sprint.

Les caractéristiques d’un bon objectif

Un bon objectif doit être :

• Centré sur la valeur utilisateur, formulé de manière simple et compréhensible par un non-expert (client, sponsor, utilisateur).

• Atteignable en un Sprint (sprints de 2 à 4 semaines maximum). 

• Cohérent avec les User Stories sélectionnées : toutes les Stories doivent contribuer directement à l’objectif.

On pourrait avoir un objectif de sprint comme : “Permettre à un nouvel utilisateur de parcourir le catalogue et de regarder sa première vidéo en toute autonomie.”

Comment définir un objectif efficace ?

1. Analyser le contexte : état actuel du produit, besoin utilisateur prioritaire, valeur livrable.

2. Impliquer toute l’équipe :

• • Product Owner → propose la direction métier.

  • Équipe de développement → définit le “comment” et le plan d’action en fonction de la faisabilité technique.

  • Scrum Master → facilite la discussion et veille à l’alignement.

3. Valider collectivement : l’objectif devient l’engagement de toute l’équipe, pas seulement du PO.

2. Les User Stories sélectionnées (le quoi ?)

Une fois l’objectif du Sprint défini, reste à répondre à une grande question : Quelles User Stories allons-nous mettre dans ce Sprint ?

C’est une étape clé, car c’est ici que l’idée devient un plan d’action clair pour l’équipe.
Et comme vous allez le voir, on ne choisit pas au hasard : la sélection s’appuie sur 2 leviers complémentaires :

• L’impact qui est la valeur créée par la Story. Il s’agit de ce qu’elle apporte à l’utilisateur ou à l’entreprise :

  • Valeur métier (revenus, conformité, performance),

  • Valeur utilisateur (satisfaction, rétention, résolution d’un problème majeur),

  • Urgence (besoin critique ou problème bloquant),

  • Visibilité (ce que l’utilisateur voit et utilise réellement).

Exemple : une fonctionnalité de paiement sécurisé a un impact élevé, car sans elle, les utilisateurs ne peuvent pas finaliser leurs achats.

• Le coût/effort, c’est-à-dire ce que la Story demande à l’équipe.
  Cela inclut :

  • Complexité technique (nouvelles technologies, dépendances, intégrations),

  • Charge de travail (temps estimé),

  • Risques (zones d’incertitude, probabilité de bugs ou retards),

  • Maintenance future (simplicité du code vs difficulté d’entretien).

Exemple : une Story « mode sombre » peut avoir un coût élevé (revoir toute l’interface) pour un impact utilisateur limité.

En croisant impact et coût, on identifie les meilleures candidates pour le Sprint :

• Fort impact / faible coût/effort → à livrer en priorité.

• Fort impact / coût/effort élevé → à planifier selon la capacité de l’équipe.

• Impact limité / faible coût/effort → intéressant si du temps reste disponible.

• Impact limité / coût élevé/effort → souvent à écarter.

Calcul concret

1. Attribuer une note à chaque critère (impact ou coût/effort) sur une échelle 1 à 5 : 1 = très faible, 5 = très élevé.

2. Pour l’impact : évaluer combien la Story améliore l’expérience utilisateur ou apporte de valeur métier.Exemple : 1 = amélioration minime, 5 = changement majeur pour l’utilisateur.

3. Pour le coût/effort : additionner ou faire la moyenne de 4 sous-critères :

• Complexité technique (1 à 5)

• Charge de travail (1 à 5)

• Risques (1 à 5)

• Maintenance future (1 à 5)

Optionnel : appliquer des poids si certains critères sont plus importants, puis faire la moyenne pondérée.

Résultat : la note finale indique “faible” (1-2), “moyen” (3) ou “élevé” (4-5).

Après avoir sélectionné les bonnes Stories, il faut vérifier si elles peuvent réellement être livrées pendant le Sprint. C’est précisément le rôle de la vélocité et des heures. 

3. Le plan en tâches concrètes (Comment ?)

Les tailles T-shirt permettent de comparer les User Stories entre elles : certaines sont petites, d’autres plus grandes.
C’est utile pour estimer la complexité relative, mais pas suffisant pour planifier un Sprint.

C’est en additionnant ces points que l’on mesure la vélocité : le nombre moyen de points livrés par Sprint.
Exemple : si une équipe termine régulièrement 20 points par Sprint, elle sait qu’elle peut planifier autour de 20 points pour les prochains, ni plus, ni moins.

• Inscription / Connexion simplifiée → S → 2 points

• Catalogue de vidéos avec recherche → M → 3 points

• Lecteur vidéo basique (play/pause) → M → 3 points

• Page d’accueil avec accès aux contenus → S → 2 points

Total = 10 points pour ce Sprint.

Si la vélocité moyenne de l’équipe est de 12 points, le plan est réaliste et laisse même un peu de marge.
Si la vélocité observée est seulement de 8 points, l’équipe devra ajuster en reportant une Story (par exemple la recherche avancée) au Sprint suivant.

Grâce à ce calcul, on transforme un objectif de Sprint en un plan atteignable, basé non pas sur des intuitions mais sur la capacité réelle de l’équipe.

Pour estimer la vélocité pour la première fois, vous additionnez les points des User Stories que vous pensez pouvoir terminer dans le Sprint, en vous basant sur votre expérience ou sur la taille des tâches, puis vous ajustez cette estimation lors des Sprints suivants selon ce qui a réellement été livré.

À vous de jouer

Contexte

Vous continuez le développement de votre application de streaming vidéo.

Votre deuxième sprint commence. Votre objectif de sprint est le suivant : « Rendre l’après-visionnage plus sympa en permettant des listes personnelles et de partage entre amis. » Ce n’est pas très clair ! Voici les User Stories choisies : 

Consignes 

1. Réécrivez l’objectif en 1 phrase claire et mesurable.

2. Choisissez 3–4 US qui y répondent le mieux.

3. Attribuez-leur des Story Points.

4. Convertissez ces points en heures selon votre repère d’équipe. N’oubliez pas la marge 20–30 % ! 

Livrable

En résumé

• Chaque Sprint a un objectif clair centré sur la valeur utilisateur, atteignable en 1-4 semaines.

• La vélocité (points réalisés par Sprint) permet de planifier de manière réaliste les tâches en convertissant les tailles T-shirt en points Fibonacci.

• Les tâches sont découpées en heures pour organiser le travail quotidien avec une marge de 20-30% pour les imprévus.

• Le Sprint Backlog devient l'outil de pilotage quotidien avec attribution claire des responsabilités.

L'organisation quotidienne passe aussi par des rituels de communication essentiels pour maintenir l'alignement de l'équipe.