Comment dois-je réagir lorsque peu de stories sont intégrées durant un sprint ?

Durant plusieurs rétrospectives, l’équipe remonte le fait que peu de stories sont intégrées. Ce qui pose question, vu que les membres ne se sont jamais retrouvés sans tâches.

Après analyse des burndowns des différentes itérations, il en ressort donc effectivement que l’équipe a une bonne productivité mais que les stories ne sont pas intégrées essentiellement pour les raisons suivantes :

• Elles sont toujours en cours de revue
• Elles n’ont pas encore commencé
• Elles sont en attente de personnes extérieures à l’équipe

Anticiper et modifier l’avenir du sprint

Hier, je regardais quelques rapports Jira d’un sprint en cours dans l’une de nos équipes, et cela m’a amené une petite discussion intéressante avec le responsable de l’équipe en question.

A première vue, tout semblait sous contrôle.

Mais à y regarder de plus près, on a vu que les graphes donnés par l’ALM montraient qu’il y avait quelques actions à mener pour terminer le sprint dans les meilleures conditions.

Cet article fait le point sur les informations que l’on peut tirer de deux graphes a priori pas très éloignés, mais qui donnent une vision parfois différente du sprint :

• le burndown chart sur le temps restant estimé, « Burndown Chart of Remaining Time Estimate » dans JIRA
• le burndown chart sur les story points, « Burndown Chart of Story Points » dans JIRA

Embaucher un développeur, à quoi faire attention

Lorsque l’on embauche un nouveau développeur, quels sont les critères qu’il est important de prendre en compte?

Pour moi, le plus important est sa compatibilité avec la culture d’entreprise.
Le deuxième critère que je prends en compte est sa capacité à progresser, que ce soit techniquement ou personnellement.

Partager son humeur avec l’équipe

Il y a deux ans, nous avons commencé à recueillir le feedback de nos développeurs via un Niko Niko Board (voir ce lien pour une explication détaillée)

Aujourd’hui, nous avons mis en place un nouveau système, moins régulier (pas de « saisie » quotidienne de son humeur), mais le loisir de pouvoir mettre à jour à souhait son humeur du moment.

Cela se trouve au milieu de la photo ci-dessous, pour notre équipe de fourmis (nos équipes ont chacune un nickname). Chaque développeur peut renseigner son humeur en collant un smiley sur le board.

Meilleure équipe du monde – 20% Free Time

Il y a un peu moins d’une semaine, j’ai présenté à l’équipe quelques innovations dans notre manière de fonctionner.

L’idée sous-jacente est de toujours améliorer la satisfaction de nos clients. Ce qui est par ailleurs déjà plutôt réussi, mais qui restera toujours un des principaux buts que nous poursuivons. Le thème est ici axé dès le départ sur la satisfaction des développeurs. C’est ainsi que nous pensons encore améliorer celle de nos clients

Les User Stories doivent être visibles… partout, tout le temps

Pour être vraiment utiles et efficaces, les User Stories doivent être visibles, tout le temps, et par toute l’équipe.

Que fait un Leader Technique chez nous?

Nos équipes de développements sont gérées par ce que nous appelons des Leaders Techniques. Voyons ensemble le rôle que nous leur avons confié.

Etre surmotivé en s’impliquant

Dans cet article, l’idée est de montrer que l’on peut obtenir facilement une énorme motivation des équipes de développement en augmentant leur implication…

Comment faire une bonne revue de code

La revue de code, en plus de régulièrement sauver un produit d’un défaut de qualité, possède nativement une multitude d’autres vertus. J’en énumère quelques unes ci-après.

Pourquoi scrumons nous?

Le Scrum Meeting est cette réunion qui se déroule en faisant passer la parole à chaque membre de l’équipe de développement. Chacun répond aux trois questions suivantes :

• Qu’ai-je terminé hier ?
• Que vais-je terminer aujourd’hui ?
• Quels problèmes je rencontre ?