Que faire lorsqu'un sprint se termine tôt?

Que faire lorsqu'un sprint se termine tôt?

En ce moment, notre équipe Scrum travaille sur des histoires du backlog, si le sprint est terminé tôt.

Que se passe-t-il avec les histoires extraites de l'arriéré? Les histoires seront-elles ajoutées au Sprint actuel? Si oui, que faire si ces histoires ne seront pas terminées à temps. Le Sprint a-t-il échoué alors?

Apportez quelque chose du backlog du projet dans le sprint (après des discussions avec Scrum Master et le propriétaire du projet).

La taille de l'article que vous entreprendrez dépendra du temps dont vous disposez. S'il n'y a rien de suffisamment petit, créez une sous-tâche d'une tâche plus grande pour la démarrer (c'est-à-dire faire une partie du travail préliminaire).

Vous pouvez également créer des tâches qui améliorent la base de code. Je n'ai jamais vu une base de code qui ne pourrait pas être améliorée d'une manière ou d'une autre. Revoir du code, ajouter plus de tests unitaires, etc.

Travailler sur des éléments de backlog de sprint étendus ou futurs semble être la chose courante à faire, ce qui a beaucoup de sens si vos éléments de backlog de sprint sont suffisamment petits et clairement définis. Cependant, les éléments de backlog qui peuvent placer le code "terminé" dans un état "plus terminé" doivent être évités.

Si le sprint est vraiment terminé, étiquetez-le, préparez-le pour la livraison, livrez-le et mettez vos référentiels de code source dans l'état "prochain sprint" afin qu'il n'y ait aucun risque que les changements de sprint tardifs mettent la livraison en danger.

Pour nous, un Sprint ne se termine jamais tôt. Nous avons seulement augmenté notre vitesse ou résolu le problème d'une manière qui nous fait faire plus de travail au sprint.

Dire que nous avons toujours un arriéré d'articles qui sont classés par ordre d'importance par nos propriétaires de produits. Lorsqu'une équipe peut intégrer plus de travail dans le sprint, il est très facile pour elle de voir quoi faire ensuite sur la liste qui s'intégrera positivement dans le temps restant des sprints compte tenu de sa vitesse.

Cela évite tout temps d'arrêt du groupe en attente de discussions avec le Product Owner / Scrum Master sur ce qui devrait être fait ensuite. Nos Product Owners et Scrum Masters restent en tête de cette liste, donc il y a toujours plus de travail à attendre pour le prochain sprint (ou en cours si le temps le permet.)

Ce que mon équipe fait, c'est extraire de l'arriéré des tâches qui sont suffisamment petites pour être exécutées en fonction du début de notre travail. Si nous en avons fini avec cela , nous donnons à notre équipe d'AQ le temps de rattraper leurs tests, et les développeurs bénéficient d'une "journée libre" - nous pouvons l'utiliser pour examiner d'autres problèmes non liés au sprint actuel, les sujets que nous voulons pour rechercher, configurer / reconfigurer nos environnements, etc.

Ne mettez pas une tonne de travail juste parce que vous avez terminé tôt. Restez fidèle à ce que votre équipe s'est engagée à faire dans ce sprint, et si un travail supplémentaire est terminé, c'est un plus formidable.

J'encouragerais le mou à être utilisé pour l'amélioration personnelle. Bien sûr, extrayez des histoires de l'arriéré, mais assurez-vous de passer du temps sur vous-même: apprenez une nouvelle langue, pratiquez votre métier avec un kata, refactorisez certaines choses, ajustez, affinez ou écrivez de nouveaux outils pour vous aider, allez parler à un intervenant, un collègue ou un client, découvrez ce que fait votre équipe d'assurance qualité, prenez le temps de comprendre comment fonctionne votre processus UX.

Il y a une énorme liste de choses que vous pouvez faire qui apporteront de la valeur à votre entreprise et à vous-même ET amélioreront votre vitesse ou la quantité de valeur de qualité que vous fournissez qui n'impliquent pas de tirer des choses d'un carnet de commandes, essayez-les d'abord.