Sprint Planning - 10 erreurs à éviter - La Minute Agile Scrum #83

0 erreurs en sprint planning - Découvrez 10 erreurs classiques de la sprint planning ! Vous voulez améliorer votre sprint planning ? Alors cette vidéo 100% sprint planning scrum est faites pour vous.
#scrum #sprint #sprintplanning
Retrouvez notre article sur le sujet sur le blog Myagile Partner :
blog.myagilepartner.fr/
Et retrouvez notre blog américain :
www.myagilepartner.com/blog/
Découvrez Scrum.sg, le blog 100% scrum guide : scrum.sg/
Le blog officiel du framing agile : www.agile-framing.com/
Découvrez RMZ sur #SoundCloud (musique d'intro)
/ user-725058568

[@StanDavid]

J’aimerais tellement « imprimer » cette vidéo et la coller sur le bureau de mon PO, je pense que je vais devoir prendre quelques pauses café/discussion ce matin :p

[@LaMinuteAgile]

David Stan Ou envoie lui la video :) Et dis lui de s’inscrire, ca lui permettra d’améliorer ses connaissances. Sinon, tu prends tous les points et tu lui offres un joli poster ;)

[@Abdelkarim-ou3hw]

Bonjour j aime beaucoup cette vidéo elle est plutôt bien détaillée

[@Abdelkarim-ou3hw]

Serait il possible de donner plus d'exemples dans tes vidéos merci d'avance

[@LaMinuteAgile]

Merci 🙏 Je pourrais essayer sans soucis

[@jean-baptistedeclerfayt8288]

Vidéo super intéressante (comme d'hab', j'apprends pas mal de trucs et puis ça rappelle bien les bonnes pratiques). J'aime aussi la petite anim en bas d'écran (pouce bleu, abonnement, cloche). Ca reste discret, ça fonctionne mieux (à mon sens) que la capsule "masque de Scream" et le message passe. Par contre, je me dis (c'est subjectif) que juste une apparition au début de ta vidéo, puis une dernière fois à la fin est largement suffisant comme appel à l'action (ce genre d'anim, ça distrait l'attention sur ton message). Encore fois, j'aime vraiment beaucoup tes vidéos et ta régularité Jude :) Hâte de voir tes prochaines vidéos :)

[@LaMinuteAgile]

Jean-Baptiste de Clerfayt hello merci pour ton com :) Je note pour les prochains montages.

[@azaneosl5284]

Trop bien

[@LaMinuteAgile]

Merci

[@emmanuelb.3755]

J ai une autre question durant un SP comment s'assurer que chaque développeur a pris suffisamment de nombre de points en charge pour un sprint de 15 jours. En d autres termes en séance je me dis qu il me faudrait peut etre un fichier excel sur le bord qui comptabilise le nombre de ticket embarqué par collegue pour m assurer que la charge est equilibrée entre les membres de l equipe ou peut etre jira permet d avoir cette vision ?

[@LaMinuteAgile]

Attention, on parle d’équipe de développement et pas de développeurs ;) Voici les pistes à suivre : 1/ déjà imaginer un objectif de sprint 2/ les membre de l’équipe s’accorde sur ce qu’elle pense pouvoir réaliser et si l’objectif proposé par le PO est réaliste. 3/ si ce n’est pas le cas, voir quel objectif est réalisable 4/ définir concrètement les éléments et le plan pour arriver à la livraison de l’incrément Le plus important n’est pas que tous les membres aient 100% de travail pour l’objectif du sprint mais de s’assurer que les éléments sélectionnés y répondent. Si un dev se retrouve finalement sans travail en cours du sprint : 1/ peut il aider à l’objectif Su sprint ? 2/ si non, que peut’il faire pour améliorer le produit Ou avancer sur le produit. Il ne faut surtout pas chercher un équilibrage parfait car il n’existe pas. L’Equipe de réalisation doit assurer pouvoir atteindre l’objectif du sprint, le reste sera du bonus défini entre l’équipe de dev et le PO. On peut sans soucis ajouter des US en cours de sprint ;)

[@emmanuelb.3755]

@@LaMinuteAgile bien compris merci bcp!

[@eve-marie5072]

Bonjour, j'ai une question concernant la certif. Parmi les questions, certaines portent sur l'attitude à avoir quand on a mal défini son objectif de Sprint planning et qu'on s'en rend compte en cours de sprint. Est-ce qu'on le change ? Est- ce qu'on le maintient coûte que coûte ? est-ce qu'on annule son sprint ? J'ai du mal à trouver des infos sur ce sujet. Merci !

[@LaMinuteAgile]

Un objectif de sprint est fixe. Si l’objectif n’est vraiment plus atteignable le PO devrait annuler le sprint. Mais cela doit se faire si c’est 100% impossible. Évidemment cela doit donner lieu à une réflexion pour que cela ne se reproduise pas

[@eve-marie5072]

@@LaMinuteAgile Merci, super sympa d'avoir pris le temps de me répondre et ça clarifie bien les choses pour moi !

[@LaMinuteAgile]

Avec plaisir :)

[@alexandrewattiez4318]

Bonjour Merci pour cette vidéo très intéressante. Et merci pour le fantastique jeu Scrum@Play qui fait toujours un carton en formation Scrum. Je me pose une question sur l’erreur n°8 : n'accepter que des US ready. Si on accepte des éléments non prêts, comment les évaluer en SP ? Nous sommes sensés définir notre engagement en planification donc comment s'engager sur des éléments pas clairs. Nous avons "solutionné" ce problème en matérialisant ces éléments par des Spikes avec évaluation pour l'étude. Une fois le sujet défini, le spike génère de nouveaux PBI qu'on évalue pendant le sprint. Ensuite soit ils sont embarqués dans le sprint en cours (en utilisant la règle du donnant-donnant), soit ils attendrons le sprint suivant pour être embarqué.

[@LaMinuteAgile]

Le story point n’est pas une science exacte. Si une Us n’est pas ready, l’équipe prendra le risque en considération pour l’estimation. Sachant que l’équipe doit s’engager, l’US non finalisée devra être à leur yeux complètement possible à réaliser... Et si encore trop d’inconnue, ils pourront la refuser.

[@LaMinuteAgile]

C’est une idée intéressante. Si elle convient à l’équipe :) Mais dans ce cas ces spike ne don’t pas parti de l’objectif du sprint je suppose

[@LaMinuteAgile]

Merci pour le jeu et pour les vidéos :)

[@alexandrewattiez4318]

@@LaMinuteAgile C'est la partie incertitude du point d'effort. Mais j'ai vu des équipes qui mettaient 20 SP (car au dessus il fallait découper ;o) sur pleins de PBI car la plupart n'étaient pas prêts et donc avec une visibilité et une prédictibilité totalement hasardeuse. Le spike a été une négociation avec l'équipe et le PO pour assainir la situation.

[@mehdizarrouri9119]

Récapitulatif des 10 erreurs à éviter lors du sprint planning : 1 - Définir des objectifs trop ambitieux 2 - Venir avec un backlog qui n'est pas ordonné 3 - Ne pas prendre assez de temps pour le sprint planning 4 - L'objectif de sprint est une suite de numéros 5 - On ne travaille pas le comment lors du sprint planning 6 - Faire le sprint planning avant la précédente revue 7 - Définir plusieurs objectifs du sprint 8 - Prendre que des user stories ready 9 - Envoyer un seul ambassadeur pour le planning 10 - Le product owner qui comprend rien

[@LaMinuteAgile]

Beau recap

[@emmanuelb.3755]

@ la minute agile Bonjour j'ai repris récemment la gestion d'un backlog orienté IT et apres avoir mené 3 sprints le constat est que de nombreux tickets sont sous évalués d'une part par l equipe de dev et que nous prenons trop de tickets qui restent bloqués en in progress car en dépendance avec des parties tierces qui ne répondent pas toujours aux equipes de dev et du coup ces tickets ne passent jamais en done. Pour le premier point j ai decidé deja de prolonger la durée du SP ils avaient pour habitude de le faire en une heure pour 15 jours de sprint et en visionnant tes videos j ai compris que c'etait une erreur mais pour ces tickets qui plombent notre vélocité je voulais avoir ton avis. Le risque si je ne les embarque pas dans le sprint c est que le responsable du ticket oubli de les suivre de relancer les personnes impliquées etc... et qu on avance jamais dans leur résolution. Est ce qu il faut se limiter a un ticket de cette typologie c est a dire en dependance avec d autres car aujourd hui je dois en avoir 4 ou 5 en cours. Je te remercie de tes conseils )

[@LaMinuteAgile]

Voici quelques règles indispensable : 1/ on ne prend que les tickets sur d’aboutir sur ils répondent à l’objectif du sprint - si il reste de la place on peut ajouter des tickets bonus 2/ si vous travaillez avec la vélocité, prenez la moyenne de la vélocité des 3 derniers sprint -> elle montrera à l’équipe ce qu’elle peut faire. Donc si les tickets semblaient sous évalué, la moyenne de la vélocité t’amènera l’équipe a une meilleure capacité de faire. Il n’y a rien de grave à une baisse de vélocité -> c’est pas représentatif de la productivité. Vous pouvez découper ces tiqueté problématiques en plusieurs afin d’embarquer la partie suivie... Vous pouvez créer un type de ticket autre que user story si vous en avez le besoin. Expérimentez et voyez si ça vous aide. Ca répond à tes questions ?

[@emmanuelb.3755]

@@LaMinuteAgile donc je comprends que si le ticket n'est pas réalisable durant le sprint car en dépendance avec des tierces on ne le prend pas. Si besoin d'un suivi pour ne pas les oublier dans le backlog creer un ticket de suivi ? 2. Concernant la velocité on se dit à chaque sprint planning que finalement il est dommage d avoir sous evalué les tickets car en réalite certains ont pris plus de temps aux equipes de dev et le cumul de points sur le sprint qui peut paraitre un peu faible n'est pas representatif de l'effort fourni par l'équipe.

[@LaMinuteAgile]

@@emmanuelb.3755 1/ Il est possible de le prendre comme "bonus" mais ne doit en aucun cas être un ticket qui répond à l'objectif du sprint. Donc si il n'est finalement pas finalisé, c'est pas un drame. L'important c'est d'atteindre l'objectif du sprint. Sinon en effet, vous pouvez imaginer des ticket type "suivi", "synchro externe" si y a un vrai soucis de dépendance... Le type d'item n'est pas imposé en scrum. L'idéal serait de ne pas à avoir le faire, mais si le contexte l'impose.... Faut le faire. Vous pouvez ainsi décider d'expérimenter et voir si ça améliore votre organisation ainsi. Si ce n'est pas le cas, vous testerez autre chose. 2/ Alors faut changer la vision de la vélocité => elle peut baisser ou monter. L'équipe par défaut réévaluera ses tickets. D'ailleurs, l'apprentissage du contexte amène souvent à revoir les estimations de façon inconsciente. La vélocité doit être utilisée pour vous aider à mieux définir la capacité de l'équipe de réalisation et en aucun cas juger sa productivité. Et si l'équipe est frustrée elle même, il faut lui expliquer que vélocité est différent de productivité ; cependant, rien ne n'empêche de réadaptée ses estimations.... Mais en réalité une équipe le fait à chaque sprint sans vraiment s'en rendre compte. Pour ça qu'on conseille d'utiliser la moyenne des 3 derniers sprint pour avoir une idée de la capacité de l'équipe. Mais à la fin, même si il y a cet indicateur, seule l'équipe de réalisation décide de sa capacité de faire ; cet indicateur n'est qu'informatif. Si une équipe a une vélocité de 34 alors qu'avant c'était en moyenne 43... Ca ne dit en rien, qu'elle est moins efficace ;)

[@emmanuelb.3755]

@@LaMinuteAgile tres interessant ce que tu m'ecris et je le partagerai prochainement avec mes collegues ça permettra d'aborder le prochain sprint sous un autre angle. Merci bcp pour tes precieux conseils

[@LaMinuteAgile]

@@emmanuelb.3755 Avec plaisir :) N'hésite pas à me dire ce qui aura marché et qui imposera de trouver d'autres possibilités