Les équipes agiles très performantes ne se contentent pas de livrer leur travail : elles prennent aussi le temps d’y réfléchir. Cette habitude de faire le point après chaque sprint pour se demander ce qui a bien fonctionné, ce qui n’a pas fonctionné et ce qu’il faudrait changer est au cœur même de l’amélioration continue, ou kaizen : de petits ajustements réguliers qui s’accumulent sprint après sprint. Mais une bonne rétrospective nécessite des éléments probants solides, et pas seulement de l’intuition. Alors que nous continuons à investir dans des méthodes de travail agiles, nous souhaitons vous donner un aperçu de la direction que nous prenons en matière de reporting agile : les rapports de sprint, les graphiques, les tableaux de bord et les analyses qui fournissent aux équipes les éléments concrets dont leurs rétrospectives ont besoin pour réellement favoriser cette amélioration.
Navigation rapide :
- Co-création avec notre communauté
- Rendre les rétrospectives moins pénibles
- Rapports de sprint
- Objectif de sprint et vue d’ensemble des lots de travaux
- Graphique burndown
- Graphique burnup
- Graphique de vélocité
- Graphique d’avancement des epics
- Graphique des éléments créés et résolus
- Diagrammes de flux cumulés
- Modifications du périmètre du sprint
- Temps de cycle et délai de livraison
- Rapports sur l’ensemble des sprints et des portefeuilles
- Personnalisation
- Pistes explorées pour les rapports agiles
Co-création avec notre communauté
Au cours des derniers mois, nous avons échangé avec des équipes utilisant Scrum, Kanban et SAFe à grande échelle, et nous avons examiné de près les lacunes en matière de reporting, en particulier pour les équipes habituées à des outils tels que Jira, où les rapports semblent souvent dispersés entre différents plugins. Ces conversations ont orienté la réflexion présentée ci-dessous. Comme toujours, il s’agit d’un aperçu de concepts et de premiers prototypes, et non d’un ensemble de fonctionnalités abouties. Nous vous le présentons dès à présent car nous souhaitons recueillir vos commentaires afin de l’améliorer encore davantage.
Rendre les rétrospectives moins pénibles
L’objectif de ce nouveau concept de reporting est simple : vous permettre de visualiser facilement le déroulement réel d’un sprint, sans avoir à exporter les données vers un tableur ni à combiner trois plugins différents. Les rapports doivent répondre aux questions qui marquent toujours le début d’une rétrospective : avons-nous mené à bien ce que nous avions prévu ? Où le travail s’est-il accumulé ? Comment le périmètre du sprint a-t-il évolué ? Sommes-nous plus rapides ou plus lents ? Et ce, sans que personne n’ait à reconstituer ces informations manuellement.
Rapports de sprint
Au cœur de ce nouveau concept se trouve le rapport de sprint : une vue d’ensemble qui résume ce qui avait été prévu, ce qui a été réalisé, ce qui a été ajouté en cours de sprint et ce qui a été reporté. Au lieu de passer au crible l’historique d’un tableau, une équipe peut ouvrir une page dès la fin du sprint et avoir immédiatement une vue d’ensemble de ce qui s’est passé, ce qui constitue un point de départ naturel pour toute rétrospective. Tout cela inclut bien sûr les graphiques dont vous avez besoin pour identifier rapidement ce qui s’est bien passé et les points qui pourraient nécessiter votre attention. Bien sûr, vous aurez également la possibilité de consulter les rapports tout au long du sprint afin de détecter les problèmes dès leur apparition.
Objectif de sprint et vue d’ensemble des lots de travaux
Votre rapport de sprint s’ouvrira sur un objectif de sprint, afin que chacun sache clairement sur quoi se concentrer. Vous disposerez également d’une vue d’ensemble de l’état général du sprint, présentant sa progression globale et les modifications apportées à son périmètre.
Graphique burndown
Le burndown classique fait peau neuve. Cet outil permettra de suivre le travail restant, en story points, en heures ou en nombre de lots de travaux, par rapport à la chronologie du sprint, afin que les équipes puissent voir d’un seul coup d’œil si elles sont dans les temps, en avance ou en retard. Nous cherchons également à faciliter la comparaison entre les prévisions de progression idéales et la progression réelle, afin que les écarts, qu’il s’agisse d’une augmentation ou d’une diminution du périmètre, soient clairement visibles.
Graphique burnup
Pour les équipes dont le périmètre évolue en cours de sprint, ce qui, soyons honnêtes, est le cas de la plupart d’entre elles, nous prévoyons d’introduire des graphiques burnup en complément du burndown. Plutôt que de se contenter d’indiquer ce qui reste à faire, un graphique burnup représente le travail achevé et le périmètre total au fil du temps, ce qui permet de mettre en évidence la dérive du périmètre au lieu de ne la constater qu’après coup.
Graphique de vélocité
Afin d’aider les équipes à planifier leurs futurs sprints avec davantage d’assurance, les graphiques de vélocité présenteront les story points réalisés, les lots de travaux achevés ou le temps passé au cours des derniers sprints. Il ne s’agit pas de chercher à atteindre un chiffre toujours plus élevé. Il s’agit de donner aux équipes une vision réaliste, étayée par des données, de leur propre débit, afin que la planification des sprints cesse d’être un jeu de devinettes et que vous disposiez d’une base fiable pour définir un périmètre de sprint adapté.
Graphique d’avancement des epics
Pour les équipes qui suivent le travail à un niveau supérieur à celui des sprints individuels, nous prévoyons un graphique d’avancement des epics, une vue indiquant, en nombre de lots de travaux ou en story points, le volume de travail terminé et le volume de travail encore ouvert au sein d’un epic. Plutôt que d’ouvrir un epic pour compter manuellement les éléments par statut, une équipe ou une partie prenante peut voir d’un coup d’œil l’avancement d’un epic, ou de plusieurs epics côte à côte. Cela s’avère particulièrement utile pour les équipes travaillant sur plusieurs sprints ou incréments de produit, lorsqu’un epic s’étend sur plusieurs semaines, voire plusieurs mois, et qu’aucun rapport de sprint ne donne à lui seul une vue complète de la situation.
Graphique des éléments créés et résolus
Pour les équipes qui doivent jongler avec un flux constant de travail entrant, de tickets d’assistance, de bugs et de demandes imprévues, nous prévoyons un graphique des éléments créés et résolus. En comparant au fil du temps le volume de travail créé au volume de travail résolu, il est facile de déterminer si un backlog diminue, reste stable ou augmente discrètement jusqu’à devenir ingérable.
Diagrammes de flux cumulés
Pour les équipes travaillant en Kanban ou dans un flux Scrumban, le diagramme de flux cumulé montrera comment les lots de travaux passent d’un statut à l’autre au fil du temps. Les bandes qui s’élargissent indiquent clairement la présence de goulots d’étranglement. Si le nombre d’éléments « En cours » ne cesse d’augmenter, c’est précisément là que l’équipe devrait concentrer son attention.
Modifications du périmètre du sprint
Grâce aux tableaux intégrés des lots de travaux, vous pouvez rapidement obtenir une vue d’ensemble de tous les lots de travaux terminés au cours d’un sprint et de ceux qui ne l’ont pas été. Les augmentations et les diminutions du périmètre seront également présentées en détail.
Temps de cycle et délai de livraison
Nous prévoyons également d’inclure le temps de cycle et le délai de livraison parmi les possibilités de reporting, deux mesures de rapidité liées mais distinctes.
Le temps de cycle permet de suivre la durée nécessaire à la réalisation d’un lot de travaux une fois que quelqu’un s’y est effectivement attelé, ce qui montre à quelle vitesse l’équipe avance une fois que le travail est pris en charge.
Le délai de livraison couvre l’ensemble du parcours, depuis le moment où une demande entre dans le backlog jusqu’à son achèvement, et reflète ainsi la durée réelle d’attente du demandeur.
L’écart entre les deux est révélateur : une différence importante indique généralement un problème de file d’attente ou de priorisation plutôt qu’un problème de vitesse, car la majeure partie du retard survient avant même que quiconque ne commence le travail. Les équipes pourront définir les statuts marquant le début et la fin de chaque mesure, puis consulter ces deux indicateurs simultanément, afin de cibler le bon problème lors des rétrospectives plutôt que de procéder par supposition.
Rapports sur l’ensemble des sprints et des portefeuilles
Pour les organisations gérant plusieurs équipes, notamment dans le cadre de SAFe, nous explorons des rapports qui agrègent les données de plusieurs sprints ou projets, voire d’un portefeuille entier. Plutôt que de consulter individuellement les tableaux de six équipes, un responsable de programme pourrait disposer d’une vue consolidée de l’avancement des epics ou du flux cumulé couvrant toutes les équipes d’un incrément de produit.
Personnalisation
Pour la première version du reporting agile, nous prévoyons de proposer une page de rapport de sprint statique. Lors des itérations suivantes, nous vous donnerons la possibilité de personnaliser les rapports de sprint par défaut, afin que vous puissiez sélectionner uniquement les graphiques pertinents pour votre équipe. Nous prévoyons également d’enrichir les tableaux de bord des projets en proposant les graphiques agiles sous forme de widgets de tableau de bord configurables.
Pistes explorées pour les rapports agiles
Ces concepts constituent notre vision du reporting agile au sein d’OpenProject. Merci à toutes les personnes qui ont participé aux entretiens avec les utilisateurs et qui ont contribué à cette vision. Nous serions ravis de connaître votre avis sur les prototypes que nous publions ici, afin de pouvoir améliorer encore davantage les fonctionnalités de reporting en fonction de vos besoins.
Ces prototypes illustrent la direction que nous souhaitons donner au reporting dans OpenProject : ils se rapprochent davantage du fonctionnement réel des rétrospectives et sont utiles aux équipes qui pratiquent Scrum, Kanban ou SAFe. Nous prévoyons de publier très prochainement la première version des rapports agiles ; restez donc à l’écoute.
