priorité

L'impact sur le vivant comme critère pour définir les priorités

L'impact sur le vivant comme critère pour définir les priorités

Nous voulons des coquelicots !

Le manifeste agile met en avant la collaboration avec le client plus que la négociation du contrat. Dans notre précédent article, nous avons constaté qu’en fait, sur le terrain, ce qui s’est passé dans les équipes agiles, c’est :

la coopération avec le Product Owner plus que la collaboration avec le client

C’est bien. Mais il est temps d’aller encore plus loin.

Prioriser avec CD3

Prioriser avec CD3

Coût du Délai Divisé par la Durée

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

Agile ou pas, il est souvent utile d’avoir des prévisions sur le moyen terme

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

Valeur, Risque, Apprentissage, Coût

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.
Le PO proxy n'existe pas

Le PO proxy n'existe pas

Si vous avez défini un rôle de Product Owner proxy, vous faites du faux agile

J’ai participé vendredi à une réunion/débat organisée par l’association Agile Toulouse sur le rôle de PO, axée sur la notion de PO Proxy. Ce billet n’est pas un compte-rendu de la réunion, j’y présente mon point de vue. Nathalie, dont c’était la fête, nous a fait une présentation de pratiques pour lesquelles le PO pouvait être assisté, par exemple pour l’animation d’ateliers de type Innovation Games. De mon côté, j’avais préparé une carte heuristique centrée sur le rôle de Product Owner.

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

Changer les priorités dans le backlog

Backlog de produit à prioriser

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.

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.

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. À l’usage cet attribut a disparu : la priorité est simplement définie par le product owner sans attribut explicite[1].