Définir et évaluer les tâches permettant de réaliser les stories. Est-ce utile ou néfaste ?


Lors de la deuxième partie du sprint planning, l’équipe revoit les stories sélectionnées dans le sprint backlog et détermine les actions à prendre pour réaliser ces stories.

Dans bien des cas, elle essaie d’identifier toutes les tâches, de la facon la plus exhaustive possible, qui seront nécessaires à l’accomplissement de la story.
En même temps elle essaie d’évaluer le temps que prendra chaque tâche. Les tâches étant découpées suffisament petites pour ne jamais depasser 2 jours hommes, on pense être en mesure d’avoir une évaluation précise.

Avons-nous besoin de ces informations ? Nous sont-elles utiles ou néfastes ?
Le besoin :
En fait le besoin exprimé pour cette information provient de notre vieille habitude de waterfall, on ne fait que transformer les sprints en mini-projets waterfall. Partant de cela on prétend avoir une analyse exhaustive et des délais parfaitement évalués.

Agir ainsi c’est un peu oublier ce qui nous amène à Scrum : reconnaitre qu’un développement de logiciel est un projet complexe d’une part, et que l’humain n’est pas habile à évaluer dans l’absolu d’autre part.

Il y a aussi un besoin de rassurance qui nous pousse à vouloir définir et évaluer : est-ce-que les stories choisies sont réalisables dans la durée d’un sprint ?
À cela deux réponses :

  • La première qui répond encore à ce besoin de plannification : Scrum, à travers l’étude statistique de la vélocité de l’équipe nous fournit un indicateur qui nous permet d’identifier le volume (en temps que complexité ) de stories qui seraient réalisables dans un sprint.
  • La deuxième sous forme de question plus philosophique : Vu que le backlog de sprint n’est absolument pas un engagement, quel est l’interêt de savoir si il est vraiment réalisable ?

Il y a aussi le product owner et le manager de l’équipe de développement qui expriment le besoin de voir que les choses avancent.
Ils disent vouloir voir que l’on est dans le temps… Dans le temps de quoi ?
Le temps lui est un élément fixe, mais dans un sprint c’est le périmètre qui est ouvert. L’équipe, elle, fait de son mieux pour réaliser un maximum de stories d’un niveau de qualité supérieure.

Et puis ultimement ce n’est pas le temps qui interesse le product owner ce sont les STORIES!
Donc la vraie métrique qui l’interesse ce n’est pas le burndown en heures mais plutôt le burnup en stories.
Le burnup en tâches est aussi une métrique interessante si on garde en tête que le découpage initial n’est pas exhaustif et qu’il s’ajoutera des tâches tout au long du sprint.

L’utilité :
Ces informations ne pourraient être utiles que dans la mesure ou elles seraient exactes.
Or elles ne peuvent être exactes que lorsque l’équipe est inchangée et collabore depuis longtemps, lorsque la technologie est maitrisée et lorsque la complexité des stories est faible et l’incertitude inexistante. Donc dans la pratique on peut affirmer que cela ne sera jamais utile ou rarement sur des projets en phase-out.

Ces informations seront en fait utiles lorsque l’on commence à adopter Scrum, elles serviront à demontrer qu’elles ne sont pas fiables et donc inutiles. C’est un peu paradoxal j’en conviens mais Je demeure convaincu que c’est une étape nécessaire de l’apprentissage et de l’appropriation de la philosophie agile scrum.

Néfastes :
Ces informations créent une pression indue et donc un stress sur l’équipe et sur le product owner. J’ai déjà lors d’un post précédent abordé le problématique du stress dans les équipes agiles-scrum, et j’avais alors expliqué le lien entre la notion de délai, de temps évalué et le stress ressenti par les membres de l’équipe.
Lorsque les membres de l’équipe débordent du temps évalué, la qualité s’en ressent immèdiatement : on tourne les coins ronds, on bacle les tests d’intègration et on oublie les tests manuels.

C’est d’ailleurs en abordant un problème de qualité par l’approche des « 5 pourquoi » que l’on a réalisé ce qui m’a amené à écrire cet article. En voici, en substance, le contenu.

Pourquoi est-ce-que la qualité n’est pas satisfaisante?
Parceque l’on n’accorde pas l’attention nécéssaire aux tests et à la qualité même.

Pourquoi on n’accorde pas l’attention ?
Parcequ’on déborde déjà du temps évalué.

pourquoi est-ce-que l’on déborde ?
Parceque l’on a sous évalué.

Pourquoi avons-nous sous évalué ?
Parceque c’est complexe et qu’on ne maîtrise pas forcement la technologie.

Pourquoi on continue à évaluer si c’est si complexe et si souvent erroné?
Pour s’assurer de se stresser inutilement ?

La solution : ne pas évaluer !

Quelle décision avons nous prise en rapport à ceci ?
Ne plus évaluer le temps des tâches, le statut « à faire », « en cours » et « fini » sera suffisant.


Voila une définition que je défend déjà. Les sponsors ont trop souvent tendance à prendre le sprint backlog comme un engagement, une liste de choses que l’équipe s’engage à realiser.

Ken Schwaber's Blog: Telling It Like It Is

Empiricism is the act of making decisions based on what is. Scrum is an empirical process, sometimes described as “the art of the possible.” By this, I mean that we do the best we can with what we have.

A Product Owner plans a release based on all current information. He or she lays out the goals, the features and capabilities that will deliver those goals, and the probable cost and date of delivery. From that point on, the Product Owner’s job is to assess what is possible given the Team’s capabilities, and to make the best decisions to reach the desired goal. Given the nature of technology, markets, requirements, and people, trade-offs are made. Sometimes the goal cannot be reached for a reasonable price. Sometimes the goal will be reached, but in a way different from what the Product Owner initially intended. This is empiricism in action.

The Team…

View original post 320 autres mots

Durée des sprints : deux, trois ou quatre semaines ?


Je vois souvent des équipes qui se demandent quelle devrait être la durée de leurs sprints ? Deux, trois ou quatre semaines ?
En fait pour répondre à cette question, il faut d’abord comprendre quelles sont les differentes variables qui influencent ce choix.

Première variable : la taille de l’équipe.
On le sait, les équipes scrum doivent être constituées de 3 à 9 membres. On parle tout de même d’un ratio du simple au triple.
Des équipes de 3 personnes ont évidemment une capacité de développement moindre, partant de cette idée, des sprints courts ne permettront pas suffisament d’ajout de valeur, les sponsors (stakeholders) risquent de perdre interet pour les sprint review.
À l’opposé, de grosses équipes utilisant des sprints longs, vont produire beaucoup de valeur à chaque sprint et necessiter beaucoup de travail de plannification en amont des sprints. Il permettrons aussi moins de changements à faible coût.

Deuxième variable : l’experience de l’équipe
Si il s’agit d’une équipe qui a peu d’experience tant au niveau de l’approche agile qu’au niveau du travail collectif, des sprints plus courts entraineront une plus grande fréquence des sprint retrospective. Plus une équipe est jeune, plus les retrospectives, si elles sont bien conduites et si on applique les pistes d’améliorations que l’on y découvre, sont importantes. Elles sont l’élément principal de l’amélioration continue de l’équipe.
Pour une équipe plus aguerrie, le besoin d’amélioration est moins présent on peut donc se permettre d’étirer un peu les sprints.

Troisième variable : la disponibilité du Product Owner
Plus les sprints sont courts, plus les meetings de sprint planning, sprint review et sprint retrospective sont fréquents, bien qu’ils soient de durées proportionnelles au sprint, plus ils sont fréquents plus c’est demandant pour le po.
Un Product owner qui gererait plusieurs projets ou équipes aurait beaucoup de difficulté à tenir le rythme.
À l’opposé un po qui ne gère qu’une seule équipe pourrait trouver des sprints de 4 semaines beaucoup trop longs et manquant d’interaction.

Quatrième variable : le besoin de changement, de réactivité
Lorsque le projet nécessite une plus grande réactivité dûe à une compétition plus féroce, un domaine jeune en plein évolution, des sprints courts offriront au Product Owner la souplesse nécessaire pour assurer une grande compétitivité.

Sachant qu’il est peu recommandé de changer la durée des sprints en cours de release, avant de définir celle-ci, verifiez ces variables pour vous assurer le bon choix.