Guide de mêlée | 17. Arriéré de sprint

L'équipe de développement crée un nouveau backlog de sprint pendant la planification de sprint. À partir de ce moment, il devient l'engagement actuel pour les Développeurs, c'est-à-dire une liste de nouvelles fonctionnalités, améliorations et modifications du Produit à mettre en œuvre dans le Sprint de départ. Après le début d'un Sprint, le Backlog devient une file d'attente contraignante à partir de laquelle les Développeurs choisissent les tâches à effectuer.

Qu'est-ce qu'un Backlog de Sprint ? - table des matières:

1. Introduction
2. Comment est créé le Sprint Backlog ?
3. Que contient le Sprint Backlog ?
4. Utilisation du backlog de sprint
5. Sommaire

Introduction

Un Sprint Backlog décrit le travail de l'équipe de développement au cours d'un seul Sprint. Par conséquent, il est exprimé en langage technique. Il décrit les tâches détaillées et leurs solutions prévues. Ainsi, il s'agit d'une liste de tâches établie de manière claire pour les Développeurs. Le Sprint Backlog tient généralement peu compte du langage de la valeur métier du Produit, mode de description propre au Product Backlog, que nous allons présenter ici.

Le Sprint Backlog se présente :

• basé sur le Product Backlog
• pour la durée d'un Sprint
• lors d'un événement Scrum appelé Sprint Planning
• par toute l'équipe Scrum - mais l'équipe de développement est le rôle clé dans sa création

Comment est créé le Sprint Backlog ?

Lors de la planification du Sprint, le Product Owner propose comment ajouter de la valeur au Produit lors du prochain Sprint. Ensuite, toute l'équipe Scrum travaille ensemble pour formuler l'objectif du sprint, c'est-à-dire, sélectionne la fonctionnalité du backlog produit à implémenter. Le Sprint Goal définit comment mettre en œuvre le Produit ou repousser l'échéance pour répondre aux attentes du Client.

La prochaine étape consiste à réfléchir et à définir de manière réaliste l'étendue du travail à faire dans le prochain Sprint et comment y parvenir.

Les résultats de ces constatations se présentent sous la forme d'une description technique des tâches à effectuer. Et cette liste devient le nouveau Sprint Backlog.

Le Sprint Backlog nouvellement créé existe dans un emplacement facilement accessible à tous les membres de l'équipe de développement. Dans l'espace physique, il s'agit généralement d'un tableau blanc suspendu dans l'espace de travail. Alors que dans l'espace numérique, il existe sous la forme d'un document partagé basé sur le cloud que tous les développeurs peuvent mettre à jour. Même si chaque membre d'une équipe Scrum doit la tenir à jour quotidiennement, c'est le Scrum Master ou l'un des développeurs qui assume généralement cette responsabilité.

Que contient le Sprint Backlog ?

Le Product Backlog ne précise pas exactement comment exécuter les tâches. C'est le rôle de l'équipe de développement de décider. Ce mouvement crée suffisamment d'espace pour que l'équipe puisse manœuvrer, améliorant ainsi ses capacités d'auto-organisation. De plus, cette liberté de choisir la séquence et les méthodes d'action donne à chaque Développeur un sentiment d' indépendance et de responsabilité.

La même idée s'applique au traitement du Sprint Backlog comme une liste non ordonnée de tâches à exécuter. Contrairement au modèle push traditionnel (où l'équipe ou le développeur agit selon un agenda prédéfini et imposé), dans le modèle pull, les développeurs sélectionnent les tâches à effectuer (modèle pull).

Le Sprint Backlog spécifie :

1. L'objectif du Sprint - c'est-à-dire une réponse à la question de savoir pourquoi effectuer les tâches planifiées ce Sprint
2. La liste des nouvelles fonctionnalités et améliorations du produit à développer dans ce Sprint. En effet, il contient les éléments du Product Backlog sélectionnés pour être implémentés dans ce Sprint.
3. La liste des tâches à effectuer - c'est-à-dire une description technique de comment et par qui le travail qui se traduira par Incremental…

Utilisation du backlog de sprint

Divers outils de métrique reflètent l'avancement des travaux écrits dans le Sprint Backlog. Le plus souvent, il s'agit du Burndown Chart , que nous aborderons en détail dans un article séparé dédié. Avec une telle visualisation, l'équipe de développement peut facilement voir si le travail sur l'objectif de sprint se déroule comme prévu.

Il peut arriver pendant un Sprint que vous trouviez que le plan de travail a été conçu de manière irréaliste. En d'autres termes, le nombre de tâches dans l'objectif de sprint du backlog produit est trop élevé ou trop faible. Dans les deux cas, les Développeurs et le Product Owner se mettent au courant des changements à appliquer au Sprint Backlog actuel. Il est possible de réduire la quantité de travail, de sélectionner des tâches supplémentaires dans le Product Backlog ou d'étendre les solutions déjà prévues. Cependant, gardez à l'esprit que l'objectif de sprint lui-même doit rester inchangé.

Sommaire

Un backlog de sprint est une liste de tâches que les développeurs prévoient d'effectuer au cours d'un sprint. C'est une sorte de contrat détaillé avec le Product Owner. Le Backlog de Sprint survient lors de la Planification de Sprint à laquelle toute l'équipe Scrum participe. Le Burndown Chart reflète le degré d'achèvement des tâches acceptées pour la mise en œuvre.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit