Dans cet article de niveau d’introduction, nous examinons la mécanique d’un Sprint et la façon dont les membres de l’équipe sont censés collaborer afin de produire un incrément de qualité de publication.

Le premier jour : Planification du Sprint

Toute l’équipe, y compris le Product Owner, se réunit le premier jour du Sprint et organise une session de Planification du Sprint. C’est la toute première chose à se produire dès le début du Sprint.

Préparation

La planification du sprint doit être préparée pour. La préparation la plus importante consiste à s’assurer que l’Arriéré de produits a été affiné à un niveau de détail approprié, avec des estimations et des critères d’acceptation (c’est le but de l’affinement de l’arriéré de produits). Ensuite, le Propriétaire du produit devrait avoir commandé le travail sur le Carnet de commandes du produit et avoir une idée générale de la façon de négocier un objectif de sprint précieux avec l’équipe. Les options de négociation d’un objectif auraient également dû être envisagées lors de l’affinement et reflétées dans l’ordonnancement des arriérés. De plus, l’équipe devrait avoir une idée de sa capacité pour ce Sprint, c’est-à-dire de la quantité de travail qu’elle croit pouvoir assumer. Ils pourront peut-être utiliser leur expérience des Sprints précédents pour les aider à déterminer la taille de ce budget.

Planifiez d’abord la valeur qui sera livrée

Chaque Sprint devrait entraîner un incrément précieux de travail terminé, en forme et prêt pour une sortie immédiate. Le Propriétaire du Produit est entièrement responsable de ce que signifie « valeur » et aurait dû commander le Carnet de commandes du Produit de manière à ce que la valeur puisse être maximisée par l’équipe, sprint par sprint. La première chose que l’équipe doit faire est donc de planifier sur quels éléments du Carnet de commandes de produits doivent être travaillés dans ce Sprint, afin que la meilleure valeur puisse être fournie à la fin de celui-ci.

Pour ce faire, l’équipe travaille avec le Product Owner pour sélectionner les articles les plus précieux du Carnet de commandes du produit qui correspondent à leur capacité projetée pour le Sprint. Gardez à l’esprit que chaque élément de l’arriéré de produits aurait dû recevoir une estimation de la part de l’équipe, afin qu’elle sache à peu près combien de travail est susceptible d’être impliqué.

Assurez-vous de convenir d’un objectif de sprint

Cette sélection de travail doit être cohérente, et pas seulement un regroupement d’éléments non liés et disparates. Rappelez-vous qu’un Sprint est une occasion en boîte de temps de réaliser quelque chose d’important. Par exemple, à la fin du Sprint, une caractéristique cohérente peut avoir été livrée ou un risque important aura été atténué. L’objectif Sprint est une simple expression de cet objectif, de la signification globale de l’œuvre sélectionnée et de la cohérence derrière la sélection.

Un bon objectif de sprint permettra à l’équipe de faire preuve de concentration et d’engagement, et permettra la collaboration et la re-planification du travail afin qu’il soit atteint.

Planifiez ensuite comment le travail sera effectué

Un Backlog Sprint est plus qu’une simple sélection de travaux avec un objectif final en tête. Il s’agit également d’un plan sur la façon dont cet objectif sera atteint et sur la façon dont le travail associé sera exécuté. Cela peut être fait en identifiant et en ordonnant les tâches techniques susceptibles d’être impliquées. En effet, le Backlog de Sprint est un plan pour atteindre l’objectif de Sprint et une prévision du travail qui devra être effectué.

Le Product Owner n’a pas besoin d’être présent pour cette partie de la planification du Sprint, car c’est à l’équipe de planifier cette prévision au niveau technique. Cependant, le Product Owner devrait être disponible, même à distance, pour répondre à toutes les questions que l’équipe pourrait avoir, et pour fournir toute clarification qui pourrait être nécessaire sur la portée du travail. Si plus d’une version est attendue pendant le Sprint, cela doit être convenu avec le PO et pris en compte dans le Carnet de commandes du Sprint.

À la fin de la planification du Sprint, une équipe doit être sûre d’avoir fait une bonne prévision du travail qui sera nécessaire pour atteindre l’objectif du Sprint. Il aura capturé ce plan dans le carnet de commandes de sprint que l’équipe possède entièrement. L’équipe devrait être en mesure de commencer à mettre en œuvre ce plan immédiatement et avec une compréhension claire – telle qu’un Burndown Sprint – de la quantité de travail restant à un moment donné.

Chaque jour, chaque jour

Une fois que l’équipe a planifié son Backlog de sprint, elle peut commencer à travailler. S’ils ont planifié des choses en tant que tâches, ils collaboreront les uns avec les autres, en équipe, pour s’assurer que ces tâches sont terminées. Ils pourront suivre leurs progrès en utilisant leur tableau de tâches et leur épuisement du travail restant.

Chaque membre de l’équipe veillera à ce que le Tableau des tâches Scrum et le Burndown Sprint soient mis à jour, afin que les informations puissent être utilisées par les autres. Un radiateur d’information doit toujours dire la vérité.

Organisez une Mêlée quotidienne

Tous les jours ouvrables, au même moment, l’équipe de développement se réunira et planifiera ce qu’elle fera pour les rapprocher de l’Objectif du Sprint. Cette réunion s’appelle la Mêlée quotidienne et ne devrait jamais prendre plus de 15 minutes.

Seuls les membres de l’équipe de développement doivent participer, car le plan de travail leur appartient entièrement. Il s’agit d’une occasion en boîte de temps de reconfigurer l’arriéré du Sprint à la suite de nouvelles découvertes et des leçons apprises pendant le Sprint. Toute l’équipe devrait participer. Chaque membre de l’équipe devrait être en mesure de rendre compte :

• Ce qu’il a fait hier pour aider l’équipe à atteindre l’objectif du Sprint
• Ce qu’il compte faire aujourd’hui pour aider l’équipe à atteindre l’Objectif du Sprint
• Tous les obstacles qui se dressent sur son chemin

À la fin de la mêlée quotidienne, l’équipe devrait avoir un plan clair pour les prochaines 24 heures et comprendre comment elle devra collaborer pour y parvenir. Ils devraient également avoir une liste de tous les obstacles qui nécessitent l’attention du Scrum Master.

Affiner le Backlog Produit

Dans Scrum, le Raffinement du Backlog Produit n’est pas un événement formel mais une activité continue – le processus d’ajout de détails, de commandes et d’estimations aux Éléments du Backlog Produit tels que les Histoires d’utilisateurs. C’est aux équipes Scrum elles-mêmes de décider à quelle fréquence le faire, bien que ce soit certainement une bonne idée pour elles d’intégrer le raffinement dans leur routine quotidienne. Le raffinement ne devrait pas prendre plus de 10% du temps total d’une équipe lors d’un Sprint. Pour la plupart des équipes, une demi-heure par jour peut suffire bien que certains préfèrent passer une heure ou deux fois par semaine. L’important est de s’assurer que le Carnet de commandes du produit est affiné en temps opportun afin que la planification du Sprint puisse se faire sans obstacle. Toute l’équipe, y compris le Propriétaire du produit, devrait participer.

Une session de raffinement commence généralement par la présentation par le Propriétaire du Produit du carnet de commandes actuel du produit à l’équipe. L’arriéré peut être conservé sous plusieurs formes, telles qu’un tableau de bord électronique ou un autre outil de collaboration, ou il peut simplement s’agir d’une feuille de calcul. Un projecteur ou un écran partagé peut être très utile.

L’équipe commence en haut du carnet de commandes de produits et se dirige vers le bas, affinant chaque article à son tour. Ils examineront chacun d’eux et discuteront de sa portée et des critères d’acceptation qui seront nécessaires à son achèvement. Chaque élément sera ensuite estimé à l’aide d’une technique telle que le Planning Poker. Un élément volumineux peut être décomposé en plus petits qui capturent plus de détails. Les épopées peuvent être décomposées en histoires d’utilisateurs, par exemple.

L’équipe s’arrête une fois la case horaire de la session épuisée. Ils recommenceront là où ils s’étaient arrêtés la prochaine fois, pour finalement recommencer au sommet afin que l’arriéré soit tenu à jour.

Collaborez toujours

Dans la pratique agile, les membres de l’équipe ne travaillent jamais isolément – s’ils le faisaient, ils ne seraient pas une équipe. En fait, le travail d’équipe est si important que le rôle est l’équipe de développement plutôt que le Développeur.

Cela signifie que chaque membre de l’équipe de développement doit collaborer avec ses pairs tout au long de la journée, car ils sont conjointement responsables de l’avancement des travaux. Tous les problèmes ou échecs appartiennent conjointement à l’équipe, ainsi que leurs succès. La collaboration n’est pas quelque chose qui se limite à des événements tels que la Mêlée quotidienne, mais s’applique à tout ce que l’équipe fait tout au long de chaque Sprint.

Exemples de collaboration ::

• Aider les pairs à terminer le travail en cours avant d’apporter un nouveau travail à partir d’un arriéré
• Programmation par paires, comme l’utiliser à tour de rôle pour utiliser le clavier et s’aider et vérifier le travail de chacun
• Examen par les pairs
• Demander de l’aide, et être désireux de le donner
• Aller là où se trouve le travail et aider, au lieu d’attendre que le travail leur soit transmis
• S’assurer que tout le travail répond en fait à la Définition de Fait
• Appeler une mêlée afin de résoudre les problèmes qui nécessitent l’attention immédiate de l’équipe
• Soulevant des obstacles à
• Mise à jour d’un tableau de tâches Scrum et d’un graphique de burndown afin que les informations soient à jour et puissent être utilisées
• Partage des compétences et des connaissances

Le dernier jour : Revue et Rétrospective

Organisez une Revue de sprint

Si une équipe a collaboré efficacement, ils auront travaillé ensemble pour atteindre l’objectif de Sprint, en gérant tous les risques et en ajustant leurs plans au besoin. Ils auront démontré leur contrôle tout au long du Sprint grâce à une réduction uniforme du travail restant, où chaque membre considérait qu’il était de sa responsabilité personnelle d’aider à terminer les travaux en cours. Ils auront un incrément précieux à démontrer au propriétaire du produit et aux parties prenantes invitées. Un examen est quelque chose qu’une équipe devrait attendre avec impatience.

C’est aussi quelque chose auquel une équipe doit se préparer. Il faut prévoir suffisamment de temps pour une démonstration du travail qui a été effectué. Des tâches peuvent être planifiées sur un Backlog Sprint à cette fin, pour s’assurer que l’examen rend justice au travail effectué et à la valeur qui est maintenant disponible. De plus, si le propriétaire du produit pense que ce serait une bonne idée d’inviter des parties prenantes, ces invitations auraient dû être envoyées. L’examen est l’occasion de célébrer le travail accompli et de mettre en valeur leurs réalisations, afin que la confiance soit inspirée et qu’un investissement continu dans l’équipe puisse être justifié.

Un examen de sprint est également une opportunité d’inspection et d’adaptation. C’est un bon moment pour le propriétaire du produit pour expliquer les performances du produit, pour obtenir des commentaires de première main de toutes les parties invitées et pour tirer des leçons qui pourraient être utilisées pour améliorer encore le carnet de commandes du produit. Si des travaux n’ont pas été achevés, pour quelque raison que ce soit, ils seront également examinés et réestimés sur l’arriéré de produits pour une éventuelle planification des sprints futurs.

Ensuite, effectuez une Rétrospective Sprint

La Revue Sprint a examiné le Produit et la valeur livrée, le travail qui a été fait, et honnêtement et franchement tout travail qui n’a pas été fait, quelle qu’en soit la raison.
La prochaine chose à faire est de mener une rétrospective Sprint. Une rétrospective examine le processus suivi par l’équipe. Travaillent-ils aussi efficacement que possible? Il est généralement préférable de tenir la Rétrospective immédiatement après l’examen, car la première peut introduire des idées à prendre en compte dans la seconde.

Toute l’Équipe de développement, le Product Owner et le Scrum Master doivent tous assister à la Rétrospective, car chacun est conjointement responsable du succès du travail de l’équipe. Il est vraiment important d’avoir une session libre et ouverte qui va au cœur des problèmes et identifie les actions qui aideront à les résoudre. Une rétrospective peut commencer par la déclaration suivante:

« Peu importe ce que nous découvrons, nous comprenons et croyons vraiment que chacun a fait le meilleur travail possible, compte tenu de ce qu’il savait à l’époque, de ses compétences et capacités, des ressources disponibles et de la situation. »

Dans un « Rétro », tout le monde a la même voix. Une approche, que le Scrum Master peut faciliter, consiste à identifier:

• Des choses qui se sont bien passées
• Des choses qui ne se sont pas si bien passées
• Des idées d’amélioration
• Des rappels pour les membres de l’équipe qui ont fait quelque chose d’exceptionnel

Établir une ligne de temps peut aider les participants à se souvenir d’événements importants pendant le sprint.