priorité

Prioriser avec CD3

Prioriser avec CD3

Le Cube de jeudi portait sur Prioriser, estimer et planifier. J’ai présenté plusieurs techniques de priorisation : HIPPO, 10/10, VRAC et CD3. CD3, c’est le Coût du Délai Divisé par la Durée. Le coût du délai est une approche économique : on calcule le coût de ne pas faire une feature et on fait en premier celle qui a le coût du délai le plus élevé. Bien sûr, cela n’est pas facile.
Prioriser, estimer et planifier

Prioriser, estimer et planifier

Prioriser, cela permet de définir l’ordre de développement. Dans le cadre de Scrum, la priorisation porte sur les éléments du backlog et indique à l’équipe sur quoi elle va travailler dans le ou les sprints qui viennent. La priorité d’une fonctionnalité est basée sur sa valeur métier, mais pas seulement. Pour affiner l’ordre de cette fonctionnalité et se projeter un peu plus loin que le travail immédiat, il convient aussi de s’intéresser à l’effort pour la développer.
Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Prochain Cube Agile à Toulouse : prioriser, estimer, planifier

Comment on priorise ? Pourquoi on estime ? À quoi ça sert ? Qu’est-ce qu’on estime avec Scrum et l’agilité ? Comment faire en sorte que le planning poker ne prenne pas trop de temps ? Comment éviter que la vélocité ne tue l’agilité ? Si, comme de nombreuses équipes vous avez des problèmes avec l’estimation, et par conséquent avec la priorisation et la planification, ce Cube est pour vous.
Critères VRAC pour la priorité dans le backlog

Critères VRAC pour la priorité dans le backlog

Prioriser est un néologisme souvent utilisé, et pas que pour un backlog. Avec Scrum, on dit que le PO priorise les éléments du backlog. Bien qu’en fait, il les ordonne. Mais sur quels critères se base t-on ? Dans l’édition 4 de mon livre, chapitre Affiner le backlog, § Revoir l’ordre, page 89, je résume ainsi : L’ordre (ou priorité ordinale) correspond au rang définissant la séquence de réalisation des stories.

En faire moins

La to do less liste. Jim Highsmith vient de publier un billet avec une idée qui m’a beaucoup plu The ‘‘to do less’’ List, qu’il reprend des fondateurs de 37 signals. Penser plus, faire moins : par tempérament, j’ai déjà tendance à suivre naturellement cette idée. De plus en plus au fil des années. Les gens veulent toujours plus, les utilisateurs en particulier. Je le vois de façon très concrète avec iceScrum, dont je suis le Product Owner.

Séminaire 'L'agilité : du projet au programme et à la ligne de produits'

IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée. Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.

L'association SigmaT a un an

et toutes ses dents. La SigmaT, association à but non lucratif qui fédère les agilistes toulousains et du sud-ouest, se diversifie pour sa deuxième année d’existence officielle. Les séminaires, qui ont accueilli des centaines de personnes, continuent tous les trimestres. Le prochain (le 13ème) est pour le 19 mars. Mais il y a maintenant des ateliers. Le premier a lieu ce soir, il s’agit du Jeu de la Valeur Métier, qui est une simulation de gestion de priorité dans un développement agile.

Le jeu de la valeur métier

Il y a un peu plus d’un an, je me disais dans ce billet sur la valeur que j’allais essayer le Business Value Game. C’est seulement hier que j’ai eu l’occasion d’approfondir cette simulation. Nous étions quelques uns de la SigmaT à nous retrouver dans notre local de la maison des associations et Pierre-Jean avait apporté le kit du Business Value Game dans sa version 2.0. Nous avons déroulé quelques itérations; il y a eu beaucoup de discussions sur la meilleure stratégie pour optimiser la valeur.

Changer les priorités dans le backlog

Du concret pour le Product Owner. Le backlog de produit est l’outil du Product Owner. Il le triture, le malaxe, pour qu’il soit toujours utile et à jour. A jour, cela implique notamment que les éléments du backlog sont ordonnés par priorité. Un Product Owner est amené à changer l’ordre de priorité pour différentes raisons : chaque fois qu’une story est ajoutée dans le backlog, il faut lui donner une priorité, par rapport aux autres éléments.

Eléments du backlog : Features, stories et spikes revisités

Que met-on dans le backlog ? L’an dernier, j’avais fait un billet sur les features, stories, epics…. Aujourd’hui je revisite ces notions à l’occasion d’évolutions dans IceScrum, qui les embarque actuellement de façon pas très limpide. Pour simplifier l’usage, nous allons fusionner les notions de thèmes et de features, et nous appuyer sur des idées de Dean Leffingwell et Philippe Kruchten. Le backlog de produit contient des éléments, qui sont :

Zorro est revenu

La valeur et le coût, c'est pas pareil

Dans son deuxième commentaire de mon billet sur la variation de périmètre, Zorro revient sur les courbes et s’y perd entre les notions de valeur, d’effort et de coût. J’essaie d’éclaircir. Le burndown chart montre l’effort qui reste à faire. Il est obtenu en collectant le nombre de points des éléments qui restent à faire dans le backlog de produit. Exemple : début du sprint 1 : 100 points à faire fin du sprint 1: 82 fin du sprint 2 : 64 fin du sprint 3 : 56 fin du sprint 4: 30 Il ne permet pas de connaitre la part due au travail accompli et celle venant du changement de périmètre dans le backlog.

Quelle valeur pour la valeur ?

Pas facile de donner une valeur à la valeur ajoutée par une user story… Dans la première version d’IceScrum, il y avait un attribut associé aux éléments du backlog de produit, qui s’appelait valeur. Je l’avais demandé parce que c’est un précepte de Scrum et des méthodes agiles que de définir la priorité en fonction de la valeur. Plus la valeur est grande, plus la priorité est importante et la priorité définit l’ordre dans lequel les éléments du backlog sont réalisés.