Au taf je dois prendre un sujet. Il y a 18 user stories en "A faire". Je ne peux en prendre aucune.
Pourquoi ? Elles ont toutes un label "à affiner", "en standby" ou "à confirmer"... ou elles sont affectées à quelqu'un.
Franchement si c'est pour fonctionner à l'arrache, autant laisser tomber les sprints et scrum et se mettre à kanban quoi.
Faut faire preuve d'un peu d'honnêteté intellectuelle.
Du cou, et si je faisais quelques rappels Scrum :
1) L'objectif numéro 1 pour l'équipe, quand on travaille en Scrum, c'est de finir le sprint.
= elle doit dire non à la moindre décision qui risquerait de se mettre en travers de cet objectif
2) Si l'équipe n'a pas assez d'informations sur certains sujets (pas maquettés, pas estimables, pas prêts, etc.) ils doivent les refuser.
= non, on ne prend pas des stories si elles ne sont pas estimables. On planifie des US d'étude/POC timeboxées pour pouvoir ensuite estimer le sujet pour le sprint suivant.
3) L'objectif de Scrum c'est de créer de la confiance. Que le développeur ait confiance dans la capacité de l'équipe à livrer la version attendue, et que le client ait confiance dans la capacité de l'équipe à délivrer chaque sprint ce qui est prévu.
= le client ne veut pas s'entendre dire "non", mais il sera davantage déçu si vous dites oui et si vous livrez en retard. Et ouais.
4) Si vous finissez moins de la moitié de vos sprints, vous ne faites pas du Scrum, mais du kanban.
= vous bossez à l'arrache, et le terme Scrum n'est là que pour faire joli, ou pour faire plaisir aux investisseurs.
5) Quand un sprint est lancé, on ne peut plus changer son contenu
= pas de modifications d'US ou d'ajout d'US, ça parait idiot, mais c'est comme ça.
6) On peut parfois faire une exception, mais il faut l'accord de l'équipe entière. Car ça les engage.
= si l'équipe dit non, c'est non. Et si on a pas le choix, alors on ANNULE le sprint et on en relance un nouveau, en repassant par les cases backlog refinement et backlog workshop.
7) L'objectif de Scrum c'est pas d'enlever les réunions et les specs, au contraire. Il faut une certaine quantité d'infos par story et de réunions (backlog workshop, backlog refinement, transformation en tâches, retro, ...) pour bien faire les choses.
= si vous faites moins de 7h de réunions par mois, inutile de chercher pourquoi vous ne terminez pas vos sprints. C'est juste que vous vous lancez dans des devs sans savoir la moitié de ce que vous êtes censés faire. Forcément ça marche pas.
8) Je pourrais également faire 20 pouets sur le rôle véritable du Scrum Master, mais j'ai la flemme. Sachez juste que :

• c'est pas un décideur
• c'est pas un product owner
• c'est pas un chef de projet ou un manager
• c'est pas forcément quelqu'un de la technique
• c'est pas quelqu'un qui doit avoir une vision technique parfaite du projet
• c'est pas un organisateur de réunions
  Au final, faire du Scrum, c'est juste faire preuve de rigueur.

  Rigueur sur ce qui rentre dans le sprint (détail des User Stories, maquettes validées, documentations d'API, ...)
  Rigueur sur le fonctionnement des sprints (temps dédié aux bugs, à la maintenance, à la dette technique, également ne pas changer les priorités ou le contenu des US)
  Rigueur sur ce qui doit sortir des sprints (testé, validé et fonctionnel)
  Le premier point est le plus important, et le plus souvent... le plus négligé. De très très loin.
  Je vais juste finir par reciter ce tweet : <A href="https://twitter.com/Tsigorf/status/1108724644004196352" rel="nofollow">https://twitter.com/Tsigorf/status/1108724644004196352</A>
  "L'agilité, c'est pas une capacité technique qu'on a ou qu'on n'a pas, c'est avant tout une faiblesse métier qu'on fait passer pour un buzzword sexy.
  L'agilité existe parce que le métier n'a aucune foutre idée de ce qu'il veut. Et qui en prend la responsabilité ? La technique."