5 – Evénements Scrum : Sprint Planning

Le Sprint Planning est le premier évènement d’un Sprint. Son objectif est de collaborer à la planification du travail à effectuer durant le Sprint. C’est un timebox de 8 heures pour un Sprint d’un mois, proportionnellement moins pour un Sprint plus court. Toute la l’Équipe Scrum y participe.

Un Sprint Planning est composé de deux parties principales.

1 – Quoi faire ?

Le Product Owner, présente une proposition de Sprint Goal correspondant à son objectif pour le Sprint et un Product Backlog ordonnancé en cohérence avec ce but.

La partie haute du Product Backlog sera composé d’éléments suffisamment petits, connus et compris par l’Équipe de Développement.

L’Équipe Scrum collabore pour définir un Sprint Goal réaliste et atteignable pour la fin du Sprint.

2 – Comment faire ?

L’Équipe de Développement sélectionne les éléments du Product Backlog qui sont réalisables dans le Sprint.

Certains facteurs ont un impact sur les estimations de l’Équipe de Développement, comme : la définition de « Fini », les performances passées, les actions d’améliorations à implémenter, la capacité de l’Équipe de Développement (congés, maladies, affectations partielles).

Pour chaque élément du Product Backlog (pas nécessairement tous), l’Équipe de Développement établira un plan de réalisation, avec plus ou moins de détail selon l’expérience.

Ce plan sera rendu transparent dans le Sprint Backlog et on acceptera qu’il change selon les informations qui émergeront au cours du Sprint.

Observations importantes

• Dans un contexte complexe, tel que le développement logiciel par exemple, les interactions ne sont jamais linéaires. Attendez-vous à revenir sur le « quoi faire » quand vous êtes passés au « comment faire », parfois le Sprint Goal change plusieurs fois au cours de la session.
• Le seul engament pris par l’équipe de Développement consiste en la réalisation du Sprint Goal. Ce n’est pas la quantité de travail, ou d’éléments du Product Backlog développés à la fin du Sprint qui compte, c’est le fait d’avoir réussi à atteindre le Sprint Goal et crée un Increment « Fini » potentiellement délivrable en production. Le plus petit qu’il soit.
• Du « Push » au « Pull » : seule l’Équipe de Développement peut faire les prévisions sur combien d’éléments du Product Backlog seront réalisés au cours du Sprint. On dit que l’Équipe de Développement « tire » (« Pull ») le travail à faire sur la base des suggestions du Product Owner. Personne ne peut leur imposer ou « pousser » (« Push ») une quantité de travail à réaliser. Renoncer à accepter cette manière de travailler, signifie déresponsabiliser l’Équipe de Développement et amène souvent à des effets de bords tels que : manque d’engagement, manque de qualité, dette technique, turnover, etc.
• La sélection des éléments du Product Backlog sera faite dans l’ordre défini par le Product Owner dans le Product Backlog. On ne choisira pas l’élément plus facile à réaliser, par convenance.
• Le Product Owner doit-il/elle rester pour la deuxième partie du Sprint Planning, le « comment faire » ? Oui ! Il/elle reste pour la raison donnée dans le premier point de cette liste. Il faut toujours s’attendre à des interactions parmi Product Owner et Scrum Master tout au long du Sprint Planning.
• Le Sprint Backlog ne sera pas détaillé pour tout le contenu du Sprint. L’important sera d’avoir suffisamment de détail pour pouvoir initier le Sprint. On acceptera l’émergence du travail au cours du Sprint.

A la fin du Sprint Planning, un Sprint Goal, des prévisions d’éléments de Product Backlog à développer (faites par l’Équipe de Développement) et un Sprint Backlog, constituant le plan de l’Équipe de Développement pour réaliser le Sprint Goal auront été créés et le Sprint pourra démarrer.

Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum, selon le Scrum Guide. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.