avez-vous essayé de les diviser en éléments de backlog significatifs?
David
pour le moment, c'est plus un problème que je pense que je rencontrerai à l'avenir - et j'aimerais le gérer correctement.
Tobias Langner
Réponses:
31
Ces éléments sont soit appelés Epic et doivent être divisés en plus petites histoires d'utilisateurs qui sont plus courtes qu'un sprint unique et à cause de cela peuvent être planifiées, ou Thème qui sera divisé en Epics et ceux en histoires communes. Les épopées et les thèmes partagent la caractéristique principale - niveau élevé d'incertitude = ils ne peuvent pas être correctement estimés (l'estimation est généralement très élevée et, à cause de cela, ils ne rentrent pas dans un seul sprint).
Il est donc bon de commencer avec de telles histoires, mais vous ne pouvez pas les planifier avant que le propriétaire du produit ne les divise en histoires plus petites et spécifiques. Ces histoires sont utilisées uniquement pour noter certaines fonctionnalités demandées plus importantes (Epic) ou des ensembles de fonctionnalités entiers (Thème). Rompre ces histoires rendra la fonctionnalité spécifique.
Il suit également la structure Iceberg du backlog produit.
Vous n'avez pas de tels objets. Si c'est le cas, l'élément de backlog n'est pas suffisamment spécifique et n'a pas été correctement divisé en éléments plus petits. Certaines personnes ne les appellent pas backlog, mais des éléments fatlog et dans Scrum, ils sont considérés comme un anti-modèle.
L'histoire de l'utilisateur de l'analogie avec les gâteaux: en tant que mangeur de gâteaux, je veux manger du gâteau l'après-midi. Je ne peux pas manger un gâteau entier en un après-midi, il doit donc être coupé en tranches pour correspondre à la quantité que je peux manger.
Lorsque Scrum a été "inventé" pour la première fois, le sprint par défaut était normalement de 4 semaines.
Selon ce que l'on m'a dit, la raison de cette très longue taille de sprint était simplement parce que les gens à ce moment-là avaient beaucoup de mal à imaginer que vous pourriez éventuellement accomplir n'importe quoi dans des sprints plus courts.
Au fur et à mesure que les équipes devenaient plus confiantes avec Scrum, elles ont appris à mieux diviser les éléments du carnet de commandes en éléments plus petits de taille plus gérable, et les équipes de développement se sont améliorées pour ne pas exagérer la conception initiale, mais en faire juste assez.
Aujourd'hui, je pense que la plupart des équipes considéreraient 4 semaines comme une très longue durée de sprint. J'ai l'impression que 2 semaines est tout à fait normal. Les équipes XP ne font que des itérations d'une semaine et terminent des user stories complètes à chaque itération.
Vous devez donc mieux diviser les éléments du carnet de commandes en éléments plus petits, qui donnent chacun une petite augmentation de la valeur commerciale au produit final. C'est possible, cela a été prouvé. (bien que je n'exclue pas qu'il puisse y avoir des domaines très spécialisés où ce serait difficile)
Je suis d'accord avec 4 semaines étant un long sprint ces jours-ci. Vous souhaitez réduire la boucle de rétroaction et améliorer la rotation de petites unités de travail dans des itérations plus courtes. De cette façon, il y a moins de problèmes, moins de changements et moins de complexité à gérer en une seule fois.
Le fractionnement des histoires est souvent un problème pour les gens, mais vous vous améliorez avec plus vous en faites. Travaillez en étroite collaboration avec le bon de commande pour déterminer si vous pouvez le livrer par étapes et toujours apporter de la valeur au sprint.
Voici une grande affiche qui aide à diviser les histoires, elle provient d'un site Web appelé agileforall.com et vous pouvez trouver l'affiche ici, c'est vraiment utile de l'avoir lorsque vous affinez les éléments du carnet de commandes:
Il est également bon d'avoir votre définition de fait disponible lorsque vous affinez et planifiez afin de pouvoir garder cela à l'esprit lorsque vous vous engagez à terminer quelque chose en un seul sprint.
Réponses:
Ces éléments sont soit appelés Epic et doivent être divisés en plus petites histoires d'utilisateurs qui sont plus courtes qu'un sprint unique et à cause de cela peuvent être planifiées, ou Thème qui sera divisé en Epics et ceux en histoires communes. Les épopées et les thèmes partagent la caractéristique principale - niveau élevé d'incertitude = ils ne peuvent pas être correctement estimés (l'estimation est généralement très élevée et, à cause de cela, ils ne rentrent pas dans un seul sprint).
Il est donc bon de commencer avec de telles histoires, mais vous ne pouvez pas les planifier avant que le propriétaire du produit ne les divise en histoires plus petites et spécifiques. Ces histoires sont utilisées uniquement pour noter certaines fonctionnalités demandées plus importantes (Epic) ou des ensembles de fonctionnalités entiers (Thème). Rompre ces histoires rendra la fonctionnalité spécifique.
Il suit également la structure Iceberg du backlog produit.
la source
Vous n'avez pas de tels objets. Si c'est le cas, l'élément de backlog n'est pas suffisamment spécifique et n'a pas été correctement divisé en éléments plus petits. Certaines personnes ne les appellent pas backlog, mais des éléments fatlog et dans Scrum, ils sont considérés comme un anti-modèle.
L'histoire de l'utilisateur de l'analogie avec les gâteaux: en tant que mangeur de gâteaux, je veux manger du gâteau l'après-midi. Je ne peux pas manger un gâteau entier en un après-midi, il doit donc être coupé en tranches pour correspondre à la quantité que je peux manger.
la source
Lorsque Scrum a été "inventé" pour la première fois, le sprint par défaut était normalement de 4 semaines.
Selon ce que l'on m'a dit, la raison de cette très longue taille de sprint était simplement parce que les gens à ce moment-là avaient beaucoup de mal à imaginer que vous pourriez éventuellement accomplir n'importe quoi dans des sprints plus courts.
Au fur et à mesure que les équipes devenaient plus confiantes avec Scrum, elles ont appris à mieux diviser les éléments du carnet de commandes en éléments plus petits de taille plus gérable, et les équipes de développement se sont améliorées pour ne pas exagérer la conception initiale, mais en faire juste assez.
Aujourd'hui, je pense que la plupart des équipes considéreraient 4 semaines comme une très longue durée de sprint. J'ai l'impression que 2 semaines est tout à fait normal. Les équipes XP ne font que des itérations d'une semaine et terminent des user stories complètes à chaque itération.
Vous devez donc mieux diviser les éléments du carnet de commandes en éléments plus petits, qui donnent chacun une petite augmentation de la valeur commerciale au produit final. C'est possible, cela a été prouvé. (bien que je n'exclue pas qu'il puisse y avoir des domaines très spécialisés où ce serait difficile)
la source
Je suis d'accord avec 4 semaines étant un long sprint ces jours-ci. Vous souhaitez réduire la boucle de rétroaction et améliorer la rotation de petites unités de travail dans des itérations plus courtes. De cette façon, il y a moins de problèmes, moins de changements et moins de complexité à gérer en une seule fois.
Le fractionnement des histoires est souvent un problème pour les gens, mais vous vous améliorez avec plus vous en faites. Travaillez en étroite collaboration avec le bon de commande pour déterminer si vous pouvez le livrer par étapes et toujours apporter de la valeur au sprint.
Voici une grande affiche qui aide à diviser les histoires, elle provient d'un site Web appelé agileforall.com et vous pouvez trouver l'affiche ici, c'est vraiment utile de l'avoir lorsque vous affinez les éléments du carnet de commandes:
http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf
Il est également bon d'avoir votre définition de fait disponible lorsque vous affinez et planifiez afin de pouvoir garder cela à l'esprit lorsque vous vous engagez à terminer quelque chose en un seul sprint.
la source