C'est le moment de la revue de sprint. Le graphique de capacité établi lors de la journée de planification est entièrement au vert et personne ne dépasse les 100 %. Pourtant, le tableau affiche encore quatre éléments en cours de « Revue » et le sprint se termine aujourd'hui. Si vous êtes Scrum Master ou chef de projet, vous avez probablement déjà vécu cette situation.
La planification de la capacité de sprint dans Jira indique qui dispose de temps, mais pas combien de temps le travail reste en attente entre deux personnes. C'est généralement là que se perdent les jours de travail. Cet article explique où disparaissent ces jours et comment les anticiper, en utilisant Activity Timeline et Timepiece - Time in Status for Jira.
Points clés: La planification de la capacité vous indique qui a du temps, mais pas combien de temps le travail reste en attente. Une tâche de 4 heures peut prendre 6 jours à être clôturée tout en paraissant normale sur le graphique de capacité. Pour respecter vos délais de sprint, suivez les deux indicateurs : la capacité dans Activity Timeline et le temps d'attente dans Timepiece.
Que mesure réellement la planification de la capacité de sprint dans Jira ?
La plupart des plans de sprint échouent avant même de commencer. Quelqu'un s'engage sur une charge de travail supérieure à son temps disponible, un jour férié non comptabilisé fait perdre deux jours, et l'équipe s'en rend compte à mi-parcours. La planification de la capacité est justement là pour éviter cela dès la journée de préparation.
La planification de la capacité compare deux chiffres. La charge de travail correspond au travail estimé assigné à un membre de l'équipe. La capacité est le temps dont dispose cette personne : ses heures de travail moins les congés, les arrêts maladie et les jours fériés. En additionnant ces données pour toute l'équipe, vous obtenez la capacité de l'équipe, soit le plafond de ce qu'un sprint peut contenir.
ActivityTimeline construit cela à partir de vos données Jira :
- La charge de travail provient de l'estimation restante des éléments de travail assignés, répartie sur les dates auxquelles ils sont planifiés.
- Les éléments de travail peuvent reprendre ces dates depuis le sprint, afin qu'ils apparaissent sur la chronologie de chaque personne pour la période du sprint.
- Sous chaque personne, un indicateur de charge de travail montre si elle est en surcharge, en sous-charge ou équilibrée.
Vous pouvez identifier qui est surchargé et déplacer les tâches avant le début du sprint, plutôt qu'après avoir pris du retard. Pour la configuration, consultez les guides d'ActivityTimeline sur la planification de la capacité dans Jira et la planification de sprint Jira.
Le graphique de capacité d'équipe agrège les données : capacité totale, capacité utilisée, capacité restante et taux d'utilisation pour la période choisie. La capacité restante vous indique la marge disponible en cas de travail imprévu, vous permettant ainsi d'accepter ou de refuser des demandes en vous basant sur des chiffres concrets.
Le développeur réservé à 130 % et le sprint qui coïncide avec un jour férié pour l'équipe sont deux exemples de la manière dont la planification de la capacité de sprint dans Jira détecte les problèmes en amont. Chaque problème identifié lors de la journée de planification est un délai que vous n'aurez pas à justifier plus tard.
Charges de travail vertes, sprint rouge : où le plan échoue-t-il ?
Voici un exemple tiré d'un sprint. Une tâche avait une estimation de 4 heures et était planifiée dans le calendrier du développeur sur ActivityTimeline. L'équipe a enregistré 4 heures de travail dessus. Pourtant, il a fallu 6 jours ouvrés pour la clôturer. (Ces chiffres sont donnés à titre illustratif.)
L'estimation était correcte : 4 heures prévues, 4 heures enregistrées. Mais les statuts « À faire », « En revue » et « En attente de QA » ont accaparé 4,5 jours sur les 6, et la majeure partie de ce temps a été perdue en attente.
Le plan de capacité n'avait rien d'erroné. ActivityTimeline calcule la charge de travail à partir de l'estimation restante et des dates prévues pour chaque élément. Un changement de statut ne modifie en soi ni l'une ni l'autre ; la tâche a donc conservé le même nombre d'heures prévues pendant qu'elle attendait en revue que lorsqu'elle était activement traitée. L'indicateur de charge de travail de personne n'est passé au rouge.
C'est toute la différence entre l'effort et le temps écoulé. L'effort correspond aux heures de travail : 4. Le temps écoulé est la durée calendaire du début à la fin, attente incluse : 6 jours. La planification de la capacité mesure l'effort, alors que votre date limite de sprint dépend du temps écoulé.
Où passe le temps entre les statuts ?
Réponse courte : dans l'attente. Le temps de chaque élément de travail se divise en deux parties :
Temps de traitement : quelqu'un travaille dessus.
Temps d'attente : l'élément est dans un statut donné et personne ne travaille dessus.
Un plan de capacité comptabilise les heures de travail estimées, ce qui correspond approximativement au temps de traitement. Le temps d'attente ne consomme les heures de personne, il n'apparaît donc jamais dans le plan. Pourtant, il grignote bel et bien des jours sur le calendrier.
L'efficacité du flux indique quelle proportion du temps total correspond au temps de traitement : temps de traitement divisé par temps total. Dans l'exemple ci-dessus, l'équipe a enregistré 4 heures sur 6 jours ouvrés (six journées de 8 heures, soit 48 heures travaillées). Si l'on considère le temps enregistré comme du temps de traitement, l'efficacité du flux est d'environ 8 %. Pendant les 92 % restants, la tâche était en attente. Dans un tel cas, réduire l'attente permet de gagner bien plus de jours que n'importe quelle accélération du travail.
L'attente a tendance à s'accumuler à quelques endroits précis :
- Revue de code : Le code est écrit, mais le relecteur est occupé par d'autres tâches.
- Transfert à l'équipe QA : L'élément est prêt à être testé, mais reste en statut « Prêt pour QA » jusqu'à ce qu'un testeur soit disponible.
- Approbations : L'élément ne peut pas avancer tant qu'un responsable, l'équipe de sécurité ou le client n'a pas donné son accord.
- Autre équipe : L'élément dépend d'une livraison préalable par une autre équipe.
- Retravail : Le contrôle qualité détecte un problème et renvoie l'élément de travail, qui doit donc repasser par les mêmes files d'attente.
Chacun de ces points constitue un goulot d'étranglement dans le flux de travail. Atlassian définit un goulot d'étranglement comme tout point d'un flux de travail où la capacité est limitée, provoquant une accumulation de travail en amont. Pour identifier les vôtres, vous devez savoir combien de temps le travail a passé dans chaque statut.
Comment identifier les goulots d'étranglement avec Timepiece ?
La plupart des équipes ont déjà une idée de l'endroit où le travail bloque. « Les revues sont lentes. » « Le contrôle qualité est toujours en retard. » Le plus difficile est de le prouver et de savoir combien de jours cela coûte.
La bonne nouvelle, c'est que Jira enregistre chaque changement de statut avec un horodatage. Mais cet historique n'est affiché que pour un élément de travail à la fois. Dans les espaces gérés par l'entreprise, le diagramme de contrôle trace le temps passé par les éléments de travail dans les statuts que vous sélectionnez, avec une moyenne et un écart-type. Cela confirme que le travail est lent. Cependant, il ne permet pas de comparer tous les statuts côte à côte, ni de savoir qui était responsable du travail. Par conséquent, la rétrospective repose sur des souvenirs, et la solution dépend de qui argumente le mieux.
Timepiece - Temps passé dans le statut pour Jira par OBSS transforme cet historique en rapports. Il lit les changements de statut déjà stockés par Jira, couvrant ainsi les sprints passés dès son installation, sans que personne n'ait à consigner quoi que ce soit. Voici les réponses qu'il apporte :
Quel statut ralentit le sprint ?
Le rapport de durée des statuts indique le temps passé par chaque élément de travail dans chaque statut. Utilisez les colonnes consolidées pour regrouper les statuts en « en attente » et « en cours » (la classification dépend de votre flux de travail), puis triez par la colonne « en attente ». Votre rétrospective peut désormais s'appuyer sur des chiffres, et non sur des impressions.
S'agit-il d'une tendance ou d'une mauvaise semaine ?
Le rapport de moyenne regroupe les résultats par sprint, par mois ou par un autre champ, comme le type de ticket. Si le statut « En revue » est lent à chaque sprint, il mérite d'être corrigé. S'il s'agit d'un pic isolé, ce n'est probablement pas le cas.
Avec qui le travail a-t-il stagné ?
Le rapport de durée par responsable et par statut affiche le temps passé par personne dans chaque statut, et la durée par groupe fait de même pour les groupes d'utilisateurs, comme les développeurs ou les testeurs. Si la majeure partie du temps « En revue » est concentrée sur un seul relecteur, cela indique un problème de charge de travail, et non une lenteur individuelle. Les données permettent de maintenir la discussion sur le processus, et non sur la culpabilisation.
Les chiffres sont-ils représentatifs ?
Un calendrier personnalisé permet d'exclure les week-ends, les jours fériés et les heures non travaillées. Sans cela, un travail transmis le vendredi soir semble subir un retard de tout le week-end, et l'équipe perd confiance dans le rapport. Le guide d'OBSS sur hors heures ouvrables montre la configuration.
À quelle fréquence le travail fait-il l'objet de retours en arrière ?
Le rapport de comptage des statuts indique combien de fois chaque élément de travail est passé par chaque statut, ce qui permet de mettre en évidence les boucles, comme le retour de l'AQ vers « En cours ».
Et vous n'avez pas besoin d'attendre la rétrospective. Les règles de surbrillance colorent les éléments de travail dont le temps de cycle dépasse un seuil que vous avez défini, et des alertes envoient un e-mail ou un message Slack ou Microsoft Teams lorsqu'un seuil est franchi. Vous pouvez débloquer le travail alors qu'il reste encore du temps dans le sprint.
Quels sont les avantages d'utiliser les deux applications ?
Timepiece montre où le travail stagne. Il ne montre pas si les personnes à cette étape ont du temps disponible. Activity Timeline, si. En les consultant ensemble, vous pouvez déterminer la solution adaptée :
- Le relecteur apparaît comme surchargé dans Activity Timeline : Il s'agit d'un problème de capacité. Transférez le travail à quelqu'un de disponible ou planifiez le temps de relecture dans le prochain sprint.
- Le relecteur est disponible, mais le travail stagne toujours : Il s'agit d'un problème de processus. Examinez le transfert : comment les relectures sont demandées, qui les prend en charge et quand.
C'est là tout l'intérêt de consulter les deux : vous investissez vos efforts dans la solution qui correspond à la cause réelle, et non dans celle qui semble logique lors de la rétrospective.
Planification de la capacité de sprint et flux : un workflow qui tient la route
Utilisez les deux vues comme une boucle :
- Planifiez la capacité du sprint dans Activity Timeline comme d'habitude. Vérifiez les indicateurs de charge de travail et le graphique de capacité de l'équipe, et tenez compte des congés.
- Pendant le sprint, surveillez le temps passé dans chaque statut dans Timepiece. Débloquez le travail qui attend plus longtemps que d'habitude.
- Après le sprint, comparez les heures prévues et les heures réelles dans le graphique « Prévu vs Réel » d'Activity Timeline. Il compare le temps planifié au temps enregistré, vous indiquant ainsi si vos estimations étaient correctes, et non si le travail a avancé rapidement.
- Utilisez ce que vous avez appris pour votre prochaine planification. Par exemple, réservez du temps de révision pour les personnes qui effectuent le plus de relectures.
Un compromis : pour une petite équipe utilisant un seul tableau partagé, un coup d'œil quotidien peut suffire. L'utilisation combinée de deux outils devient avantageuse lorsque plusieurs projets impliquent les mêmes personnes, car les files d'attente sont alors plus difficiles à identifier visuellement.
Quelles métriques analyser conjointement ?
Un chiffre isolé révèle rarement ce qui a échoué. En comparant côte à côte les vues de chaque application, la raison pour laquelle un sprint a pris du retard devient généralement beaucoup plus claire.
Les chiffres vous indiquent où chercher. Votre équipe peut vous expliquer pourquoi cela s'est produit.
Découvrez où est passé le temps de votre sprint
Un graphique de capacité au vert signifie que votre équipe disposait du temps nécessaire. Cela ne signifie pas pour autant que le travail a progressé. Lorsqu'un sprint prend du retard alors que personne n'était surchargé, les jours perdus se trouvent généralement dans une file d'attente : en attente de révision, de contrôle qualité ou de validation.
La capacité indique l'effort, le flux indique le temps, et votre échéance est fixée par le calendrier.
Vous voulez savoir où est passé le temps de votre sprint ? Les deux applications proposent un essai gratuit sur l'Atlassian Marketplace :
- Essayez Activity Timeline pour planifier la capacité de vos sprints en fonction de la disponibilité réelle.
- Essayez Timepiece - Time in Status for Jira pour voir combien de temps le travail reste dans chaque statut.
Vous ne savez pas si votre file d'attente est due à un problème de personnel ou de processus ? Lisez l'article complémentaire sur le blog d'OBSS.
