… à l'Ecole de la V.I.E …

Le Lean (ou Pensée Lean) est le nom anglais, popularisé par des chercheurs du MIT, pour décrire le système aujourd’hui connu comme la Méthode Toyota au sein de l’entreprise qui l’a créée, aussi appellé TPS (Toyota Production System).

L’essence du TPS est l’engagement du management d’une entreprise à constamment investir dans ses individus et promouvoir une culture de l’amélioration continue.

L’essence du système Toyota est d’autoriser chaque employé à trouver des problèmes dans son travail, à les résoudre et à procéder à des améliorations (Wakamatsu et Kondo, experts de chez Toyota).

Le TPS repose sur 2 principes:

– d’abord construire les gens, et ensuite construire les produits

– mettre en place une culture d’amélioration continue qui n’hésite pas à « remettre en cause la pertinence des choses établies »

L’avantage réel de Toyota reposant sur sa capacité à exploiter l’intelligence d’employés « ordinaires » a fait le succès du TPS.

Le Lean n’est pas un corpus figé d’outils, mais une dynamique quotidienne d’amélioration continue emmenée par la base avec le soutien des cadres.

Le Lean est une méthode de management qui vise à l’amélioration des performances de l’entreprise par le développement de tous les employés.

Les 2 piliers du Lean :

– le Respect des personnes

– l’Amélioration Continue

Le respect est nécessaire pour travailler ensemble. « Personnes » signifie employés, fournisseurs et clients… Pas seulement le client final ; sur une chaîne d’assemblage, la personne au prochain atelier est aussi votre client. Cela favorise le travail d’équipe. En adoptant ce principe, vous vous poserez sans cesse la question de savoir si vous faites parfaitement les choses, sans gêner votre client. Cela nourrit votre capacité à identifier les problèmes, et si vous observez attentivement les choses, cela favorisera le Kaizen (Amélioration continue). La base de la méthode Toyota est de ne pas se satisfaire du statu quo, vous devez constamment vous poser la question : « Pourquoi faisons-nous ça ? ».

L’amélioration continue, souvent nommée Kaizen, définit l’approche basique de Toyota pour faire son métier. Remettre tout en cause. Plus important que les améliorations auxquelles chacun contribue, la vraie valeur de l’amélioration continue est dans la création d’une atmosphère d’apprentissage continu et dans un environnement qui ne fait pas qu’accepter, mais qui réellement embrasse le changement. Un tel environnement ne peut-être créé que là où il y a un respect des personnes, c’est le second pilier de la méthode Toyota.

La maison de la pensée Lean :

– les fondations : des managers-formateurs formés à la pensée Lean

– les piliers : « respect des personnes » et « amélioration continue »

– le ciment : les 14 principes Lean

– le toit : le but du Lean, c’est à dire livrer la valeur-métier à un rythme rapide et durable

– l’intérieur : le développement Lean de produits

 Si vous vous intéressez à la pensée Lean, il est facile de voir que c’est un vaste système qui couvre tous les groupes et les fonctions de l’entreprise, y compris le développement de produits, les ventes, la production, les services et les RH. Le Lean s’applique à toute l’entreprise. La pensée Lean, c’est beaucoup plus que des outils tels que le management visuel ou la théorie des files d’attente, ou simplement l’élimination des gaspillages. Comme on peut le voir chez Toyota, c’est un système d’entreprise reposant sur le fondement de managersformateurs au mode de pensée Lean, avec comme piliers le respect des personnes et l’amélioration continue. Son introduction réussie va prendre des années et nécessite un enseignement généralisé et du coaching. Pour citer une nouvelle fois Fujio Cho, président de Toyota : Beaucoup de bonnes entreprises américaines ont le respect des personnes, et pratiquent le kaizen ainsi que d’autres outils [lean]. Mais ce qui est important c’est d’avoir tous ces éléments réunis ensemble comme un système. Il doit être pratiqué tous les jours de manière très cohérente…

En conclusion le Lean permet de :

– de traquer les déchets (Waste)

– d’effectuer les tâches en petits lots (small batches) à la demande (pull)

– de voir le système dans son intégralité, pas d’optimisations locales

– d’avoir une Equipe soudée et motivée (Jelled Team)

– d’apprendre et d’améliorer le processus en continu (Kaizen)

– d’être accompagné par un Manager qui écoute et règles les problèmes de son équipe (Gemba)

En conclusion, ce petit aperçu montre que les pratiques Agiles sont un support efficace au déploiement d’une démarche Lean.

Lean met le produit au coeur de son concept, ce qui permet une fois de plus, de faire converger ces deux approches.

L’essentiel à retenir du Lean :

Le Lean est basé sur les principes fondamentaux suivants :

• déterminer ce qui crée de la valeur pour le client,

• identifier le flux de valeur,

• le rendre continu,

• rechercher la perfection.

Grâce aux méthodes Agiles, les développeurs sont en mesure de générer quotidiennement une version compilée de l’application en cours de développement, afin de détecter au plus tôt les anomalies potentielles.

Les pratiques Agiles sont un support efficace au déploiement d’une démarche Lean.

Dans le monde IT, il faut apprendre à identifier le muda :

– suproduction

– surstock

– transports inutiles

– surprocessing

– mouvements inutiles

– erreurs/défauts

– temps d’attente

– savoir non capiltalisé

– opportunités non saisies ou gâchées

Pour compléter cet article, voir aussi:

Agile et les piliers de maison Lean

Agile et les fondations de la maison Lean

Agile, Lean et Kaizen

Agile, Lean et la notion de flux

Agile, Lean et le développement Lean de produit

Agile et les 14 principes Lean

Agile et le but de Lean

Les méthodes Agile utilisent beaucoup la notion de juste à temps (Just In Time), être juste à temps, c’est faire juste ce qu’il faut quand il faut pour éviter le stock synonyme de gaspillage (Muda).

Il faut donc désapprendre à faire bien pour faire juste à temps, c’est à dire :

● Oublier la perfection

● Faire la chose juste

● Faire la chose bien

● La réduire au minimum viable

● Collaborer

● Avoir du feedback interne rapidement

● Avoir du feedback client rapidement

Vous supportez le modèle « juste à temps » en développant des signaux dans le système pour vous informer que vous devz remplacer, commander ou trouver quelque chose.

Le focus est mis sur la réduction de la surproduction, de manière à ce que vous ayez ce dont vous avez besoin, seulement au moment où vous en avez besoin, pas plus, pas moins.

Il faudra collaborer ensemble entre Client et Fournisseur pour se mettre d’accord sur la définition de « fini » (Definition of Done).

Fini

Dans le monde Agile, on parle souvent de Kanban, qu’est-ce donc ?

Origine du Kanban :

Le Kanban est un outil du lean management qui, selon Taichi Ohno est un des moyens permettant d’atteindre le JIT (Just In Time). Il permet à un ensemble de processus de fonctionner en flux tiré en mettant en place un certain nombre de règles que toutes les équipes travaillant sur un projet se doivent de respecter.

A quoi sert Kanban ?

Le Kanban sert à matérialiser les tâches en cours dans un projet et à savoir qui s’en occupe.

Le Kanban est, à la base, une façon de représenter graphiquement des informations sur des cartes.

Il peut être utilisé pour décrire des tâches ou surveiller des stocks.

Mais il peut également servir d’outil de gestion de l’état d’avancement d’un projet.

Il couvre alors toutes les activités (et tous les départements) de ce projet depuis le département marketing et les premières idées sur un nouveau produit jusqu’à la réalisation et enfin jusqu’à la livraison.

Les 4 principes kanban :

· Visualiser la production actuelle

· Identifier les goulots d’étranglement et les traiter si l’on en trouve pour lisser l’activité

· Améliorer les processus de production en continu par l’utilisation du flux tiré

· Atteindre le « Kaizen » (amélioration continue) à partir des 3 éléments précédents : il faut optimiser la façon dont se déroulent tous les processus pour obtenir l’activité la plus lissée possible et, de ce fait, éviter les à-coups de production et donc les gaspillages de toutes sortes (stocks, personnes inactives …)

5 pratiques Kanban pour améliorer les processus :

• Visualiser le flux

• Limiter le travail en cours

• Gérer le flux de travail

• Rendre explicite les règles de gestion du processus

• S’améliorer de manière collaborative

Comment utiliser Kanban :

Dans le cas de la gestion des tâches à effectuer (dans un projet informatique typiquement), cela prend en général la forme d’un tableau (un peu comme la représentation d’une usine et de ses différentes parties) recouvert de post-it symbolisant des User Stories à compléter.

Le kanban va en général être découpé en plusieurs zones, typiquement selon les équipes (ou les aspects « métier » concernés) :

· Il existe des tâches « normales » et des tâches « critiques » (en général en retard). Pour chaque zone on peut décider de faire passer un certain nombre de tâches en statut « critique ». Ce nombre est désigné à l’avance et est en général fait pour ne pas tomber dans le travers de planification qui consiste à estimer que tout est critique (si toutes les tâches deviennent critiques, la notion de criticité n’a alors plus aucun sens) · S’il y a une tâche « critique » pour une équipe, elle doit se concentrer exclusivement sur celle ci avant d’envisager autre chose.

· Il y a un nombre maximum de tâches que l’on peut faire entrer dans chaque zone du Kanban et ce afin d’éviter les goulots d’étranglement. L’idée sous-jacente est que les équipes de chacun des domaines couverts par le projet ne travaillent pas forcément à la même vitesse (parfois tout simplement parce que cela n’est physiquement pas possible). Cela amène chaque équipe, de façon incidente, à prioriser son travail de sorte à produire très tôt les éléments les plus importants (ceux produisant la plus forte valeur ajoutée) pour que la production à un instant t intègre la plus grande valeur ajoutée possible en fonction de ce que l’on souhaite produire.

· D’autres règles encore peuvent venir se greffer sur un Kanban mais elles sont en général spécifiques à un projet. L’idée est de mettre à disposition de tous un outil adapté plutôt qu’un frein.

Une telle représentation graphique permet à chaque personne qui travaille sur le projet de pouvoir facilement consulter son avancement ainsi que les éventuels points de blocage et ce sans être technicien ou spécialiste en méthodologie. Le principal but d’un tel outil est que l’état d’avancement du projet soit « abordable » pour n’importe qui, y compris quelqu’un ne faisant pas partie de l’équipe projet. Une telle représentation fournit un support autour duquel toutes les équipes travaillant sur le projet peuvent discuter et, au besoin, se mettre d’accord sur les prochaines actions à effectuer avec l’avantage d’être un outil « concret » (on déplace les post-its, les reformule …), et qui oblige à formuler ce que chaque User Story implique.

Le tableau Kanban :

Le tableau Kanban est constitué de 3 colonnes:

– à faire (To Do)

– en cours (In Progress)

– fini (Done)

Quelquefois la colonne « en cours » est séparée en 3 colonnes:

– en cours de développement

– en cours de tests

– en cours de livraison

Kanban et flux tiré :

• la planification ne s’effectue plus par mesure de la vélocité dans une itération

• on cherche à garantir un temps de traversée

• on impose des limites de stock sur les colonnes d’états du tableau des items (par exemple, pas plus de 3 items en cours de développement)

Temps de traversée et de cycle :

• L’horloge du lead time démarre lorsque la demande est faite et se termine lorsqu’elle est satisfaite (délai et non effort). Le lead time est ce que le client voit.

• L’horloge du cycle time démarre lorsque le travail sur la demande commence et se termine lorsque la solution est prête à être livrée. Le cycle time est ce sur quoi l’équipe peut influer.

Le système Kanban :

Là où Scrum tend à se focaliser sur le sprint, un système Kanban se focalisera davantage sur le flux d’un élément individuel au travers du système.

Kanban préconise la limitation :

• des files d’attentes

• du travail en cours

Dans un système Kanban :

– la vélocité est remplacée par le temps de cycle

– il y a disparition des time-boxes

– l’estimation est optionnelle (il se peut même qu’il n’y ait pas d’estimation du tout)

Les Cérémonies dans le framework Scrum

– Planification du Sprint (Sprint Planning)

Chaque Sprint démarre avec une réunion timeboxée qui s’appelle la Planification du Sprint (Sprint Planning).

Au cours de cette réunion, l’Equipe Scrum collabore pour sélectionner et comprendre le travail à réaliser dans le Sprint à venir. L’équipe entière participe à la réunion de Planification du Sprint. A partir du Backlog Produit ordonné, le Product Owner et les membres de l’Equipe de Développement discutent de chaque item pour en partager une compréhension commune et déterminer ce qui est nécessaire pour le réaliser en respectant l’actuelle Définition du Fini (Definition of Done). Toutes les réunions Scrum sont timeboxées. La durée recommandée pour la Planification du Sprint est de deux heures (ou moins) par semaine de Sprint. Etant donné que cette réunion est timeboxée, le succès de cette réunion de Planification du Sprint repose en grande partie sur la qualité du Backlog Produit en entrée.

C’est pourquoi le Raffinement du Backlog Produit (Product Backlog Refinement) est une activité importante.

Dans Scrum, la réunion de Planification du Sprint est décrite comme ayant deux parties :

– 1. Déterminer quel travail devra être réalisé dans le Sprint.

– 2. Déterminer comment le travail sera accompli.

Partie 1 : Quel travail devra être réalisé ?

Lors de la première partie de la réunion, le Product Owner présente les items du Backlog Produit ordonné à l’Equipe de Développement, et l’Equipe Scrum entière collabore pour comprendre le travail à réaliser. Le nombre d’items du Backlog Produit à prendre dans le Sprint est de la seule responsabilité de l’Equipe de Développement. Pour décider du nombre d’items à prendre, l’Equipe de Développement prend en compte l’état actuel de l’Incrément Produit, la performance passée de l’équipe, la capacité courante de l’équipe, et le Backlog Produit ordonné. Seule l’Equipe de Développement décide de la quantité de travail à prendre en compte. Ni le Product Owner, ni toute autre forme de pouvoir, ne peut pousser du travail supplémentaire à l’Equipe de Développement. Souvent, mais pas toujours, on donne un objectif au Sprint, appelé l’Objectif du Sprint (Sprint Goal). C’est une pratique puissante qui permet à toute personne de se concentrer sur l’essence de ce qui doit être réalisé, et moins sur les petits détails d’une importance toute relative par rapport à ce qui doit être réellement accompli.

Partie 2 : Comment le travail sera t’il accompli ?

Dans la seconde partie de la réunion, l’Equipe de Développement collabore pour décider comment produire le prochain Incrément Produit, en accord avec l’actuelle Définition du Fini (Definition of Done). Les membres de l’équipe réalisent le travail de conception et de planification nécessaires et suffisants pour avoir confiance dans le fait de terminer le travail pendant le Sprint. Le travail à réaliser assez tôt est découpé en petites unités de moins d’une journée. Le travail à réaliser plus tard peut être laissé sous forme de grosses unités à décomposer ultérieurement. La décision de comment faire le travail est de la responsabilité de l’Equipe de Développement, de même que la décision de quel travail doit être fait est de la responsabilité du Product Owner. Le Product Owner peut rester pendant cette partie de la réunion, pour répondre aux questions et lever les incompréhensions. Dans tous les cas, il doit rester disponible.

La Planification du Sprint permet à l’Equipe Scrum de partager une compréhension commune de la quantité et de la complexité de ce qui devra être accompli pendant le Sprint, et compte tenu des circonstances, on s’attend à ce qu’elle finisse tout. L’Equipe de Développement prévoit la quantité de travail qu’elle pourra terminer et ses membres s’engagent mutuellement à le réaliser.

Pour résumer, lors de la Planification du Sprint, les membres de l’Equipe de Développement :

• Examinent et discutent des items du Backlog Produit avec le Product Owner,

• S’assurent qu’ils les comprennent, • Sélectionnent un certain nombre d’items qu’ils prévoient d’accomplir,

• Et créent un plan suffisamment détaillé pour garantir la réalisation des items. Le résultat de cette liste de points est appelé le Backlog du Sprint (Sprint Backlog).

Mêlée Quotidienne (Daily Scrum)

L’Equipe de Développement est auto-organisée.

L’Equipe de Développement utilise la Mêlée Quotidienne (Daily Scrum) pour s’assurer qu’elle est bien en situation d’atteindre l’Objectif du Sprint (Sprint Goal). La réunion a lieu au même endroit et à la même heure tous les jours.

Chaque membre de l’Equipe de Développement communique trois éléments d’information :

• Qu’est-ce que j’ai terminé depuis notre dernière Mêlée Quotidienne ?

• Qu’est-ce que je prévois de terminer entre maintenant et notre prochaine Mêlée Quotidienne ?

• Qu’est-ce qui m’empêche de progresser ?

Cela peut donner lieu à de rapides questions / réponses pour clarifier les choses, mais on ne discute pas des sujets lors de la Mêlée Quotidienne. Même si certaines équipes se revoient juste après la Mêlée Quotidienne pour travailler sur les problématiques qui ont émergé.

La Mêlée Quotidienne n’est pas un reporting, ni pour le management, ni pour le Product Owner, ni pour le ScrumMaster. Il s’agit d’une réunion d’information au sein de l’Equipe de Développement, pour s’assurer que ses membres sont alignés. Seuls les membres de l’Equipe de développement peuvent parler lors de cette réunion. Si le ScrumMaster et le Product Owner ont participé aussi au développement, ils peuvent parler. Les autres parties intéressées peuvent venir écouter. Sur la base de ce qui émerge lors de cette réunion, l’Equipe de Développement peut réorganiser sont travail comme elle le souhaite pour atteindre l’Objectif du Sprint.

La Mêlée Quotidienne est un élément essentiel de Scrum, qui améliore la transparence, la confiance et la performance. Elle permet d’identifier rapidement les problèmes, de soutenir l’auto-organisation de l’équipe et sa confiance en elle-même. Toutes les réunions Scrum sont timeboxées. La durée (timebox) recommandée pour une Mêlée Quotidienne n’excède pas 15 minutes.

Revue de Sprint (Sprint Review)

A la fin de chaque Sprint, l’Equipe Scrum et les parties prenantes examinent le résultat du Sprint. Toutes les réunions Scrum sont timeboxées. La durée (timebox) recommandée pour une Revue de Sprint est de 1 heure par semaine de Sprint. L’élément au centre de la discussion est l’Incrément Produit terminé lors du Sprint. Etant donné que les parties prenantes (stakeholders) sont celles qui ont des enjeux (stake) par rapport aux résultats, il est généralement logique et utile pour elles d’assister à la réunion. Il s’agit dune réunion informelle qui permet de savoir où nous en sommes et de collaborer pour savoir où nous pourrions aller. Chaque participant peut faire des propositions lors de la Revue de Sprint. Naturellement, le Product Owner prend au final les décisions nécessaires pour l’avenir, et met à jour le Backlog Produit en fonction de ses décisions. Les équipes trouvent elles-mêmes la manière de réaliser une Revue de Sprint. Une démonstration de l’Incrément Produit est habituellement réalisée. Les participants discutent souvent de ce qu’ils ont observé durant le Sprint, des idées qui leur sont venues à l’esprit. Ils discutent de l’état du Backlog Produit, des éventuels prochains jalons, et de ce qui pourrait être réalisé d’ici là. La Revue de Sprint donne à chaque participant une vue globale de l’Incrément Produit actuel. Sous cet angle, il est habituel de mettre à jour le Backlog Produit pendant la Revue de Sprint, c’est ce que l’on appelle le Raffinement du Product Backlog.

L’activité Raffinement du Backlog Product : étant donné que les Items du Backlog Produit sont très souvent gros et étendus par nature, et puisque les idées vont et viennent et que les priorités changent, le Raffinement du Backlog Produit (Product Backlog Refinement) est une activité récurrente du projet Scrum.

Cette activité inclut notamment :
Maintenir le Backlog Produit ordonné
Supprimer ou déprioriser les items qui ne semblent plus importants
Ajouter ou reprioriser les items émergents ou qui deviennent plus importants
Découper les items en plus petits items
Fusionner les items en plus gros items
Estimer l’effort de réalisation des items

L’un des bénéfices essentiels de l’activité de Raffinement du Backlog Produit est de préparer les Sprints à venir.

Pour cela, l’activité de raffinement porte une attention particulière à la préparation des items qui devront être prochainement réalisés. Il y a beaucoup de choses à prendre en compte, notamment :

– chaque item qui entre dans le Sprint doit idéalement représenter un incrément de « valeur métier » (business value),

– l’Equipe de Développement doit être capable de fabriquer chaque item en un seul Sprint.

Tout le monde doit être au clair sur ce qui est prévu. En fonction de la nature du produit, d’autres entrées et compétences seront peut-être nécessaires.

Dans tous les cas, il vaut mieux considérer que le Raffinement du Backlog Produit est une activité qui incombe à tous les membres de l’équipe, pas juste le Product Owner.

Rétrospective de Sprint (Sprint Retrospective)

A la fin de chaque Sprint, l’Equipe Scrum se réunit pour une Rétrospective de Sprint (Sprint Retrospective).

L’objectif est d’examiner la façon dont les choses se sont déroulées vis-àvis du processus, des relations entre les personnes et des outils. L’équipe identifie ce qui a bien fonctionné (what went well) et ce qui a moins bien fonctionné, et identifie d’éventuelles améliorations. Les participants en sortent avec un plan d’actions pour améliorer les choses dans l’avenir. Toutes les réunions Scrum sont timeboxées. La durée (timebox) recommandée pour une Rétrospective de Sprint est de 1h par semaine de Sprint. L’Equipe Scrum améliore son propre processus, tout en restant dans le cadre de travail Scrum.

Les Artéfacts dans le framework Scrum

Backlog de Produit

Le Backlog de Produit (Product Backlog) est un artéfact essentiel de Scrum.

Le Backlog Produit est une liste ordonnée d’idées /items pour le produit, maintenue dans l’ordre attendu de réalisation. C’est l’unique source dont découlent toutes les exigences. Cela signifie que tout le travail que l’Equipe de Développement réalise provient du Backlog Produit. Chaque idée de fonctionnalité, amélioration, correction d’anomalie, exigence de documentation, toute partie du travail réalisée, dérive d’un item du Backlog Produit.     Chaque item du Backlog Produit porte une description et une estimation.

Le Backlog Produit peut commencer sous la forme d’une grande liste ou d’une petite. Il peut être flou ou plus détaillé en fonction du niveau de visibilité. Typiquement, il commence sous la forme d’une petite liste pas très détaillée et devient de plus en plus grand et de plus en plus précis au fil du temps.

Les items du Backlog Produit dont la réalisation est prévue à court terme, devront être « raffinés » (refined) : clarifiés, mieux définis, découpés en petits morceaux, dans le cadre de l’activité de Raffinement du Backlog Produit.

Le Product Owner est responsable et redevable de maintenir le Backlog Produit, même si le Product Owner pourrait, et devrait même, être aidé pour le produire et le maintenir à jour.

Les items du Backlog produit peuvent être générés par le Product Owner, les membres de l’équipe, ou d’autres parties prenantes.

Backlog de Sprint

Pour constituer le Backlog de Sprint (Sprint Backlog), il faut s’appuyer sur la liste raffinée des items du Backlog Produit. Il faut tenir compte de la capacité de l’equipe de développement et on prend autant d’items de plus haute priorité qu’il est possible d’en développer pendant le Sprint. Ces items sont ensuite éclatés en tâches et estimés en heures de travail.

Le Backlog de Sprint est donc une liste de tâches estimées. Il reflète le degré de prévision de l’équipe sur le travail qui devra être réalisé.

L’Equipe de développement se répartit le travail sur la base du volontariat.

Une fois le Backlog du Sprint en place, le Sprint démarre et l’Equipe de Développement développe le nouvel Incrément Produit défini par le Backlog du Sprint.

Pendant le Sprint, l’Equipe de Développement s’auto-organise pour produire un Incrément Produit en fonction du Backlog de Sprint, déterminé lors de la Planification du Sprint.

L’auto-organisation signifie que l’équipe se responsabilise pour produire l’Incrément Produit en accord avec les standards de l’organisation, avec la Définition du Fini (Definition of Done), et aussi qu’elle choisit elle-même comment travailler avec ces éléments.

Incrément de produit

L’artéfact le plus important dans Scrum est l’Incrément Produit (Product Increment). Chaque Sprint produit un Incrément Produit.

L’Incrément Produit doit être de qualité suffisante pour être potentiellement livrable aux utilisateurs.

L’Incrément produit doit satisfaire la Définition du Fini (Definition of Done) actuelle dans l’Equipe Scrum, et chacun de ses composants a été accepté par le Product Owner.

Lorsqu’un travail est « complété », il est absolument nécessaire que tout le monde ait la même compréhension de ce que cela implique.

Bien que cela varie considérablement par Scrum Team, les membres doivent avoir une compréhension commune de ce que cela signifie pour le travail que d’être terminé afin d’assurer la transparence.

Lorsque l’Incrément Produit est livré, il est déclaré dans un état « fini » qui renvoie à une compréhension partagée de ce que le terme « fini » signifie.

Cette définition diffère d’une Equipe Scrum à une autre, et au fur et à mesure que l’équipe monte en maturité, la Définition du Fini (Definition of Done) évolue pour gagner en précision et pertinence.

La Définition du Fini embarque toujours la notion que l’Incrément Produit a vocation à être d’un niveau de qualité suffisant pour être déployable (shippable) : le Product Owner peut décider de le déployer immédiatement.

L’Incrément Produit inclut les fonctionnalités de tous les Incréments Produits précédents, il a subi des tests complets qui garantissent que tous les items du Backlog Produit continuent de fonctionner ensemble.

Les rôles Scrum :

Product Owner

Le Product Owner est la seule personne responsable pour que l’on puisse extraire un maximum de valeur du produit avant une échéance donnée. Ceci est réalisé en suivant le travail de l’équipe, en sélectionnant et en précisant des éléments du Backlog Produit.

Le Product Owner maintient le Backlog Produit et s’assure que chacun sait ce qu’il y a dedans et quelles sont les priorités.

Le Product Owner peut être assisté par d’autres personnes, mais le rôle de Product Owner n’est porté que par une seule personne.

Le Product Owner est typiquement l’individu le plus proche du côté métier dans le projet.

Le Product Owner est typiquement chargé, par l’organisation, de « sortir ce produit ». C’est également typiquement la personne chargée de faire le meilleur travail possible pour satisfaire toutes les parties prenantes.

Le Product Owner fait cela en gérant le Backlog Produit, et en s’assurant que le Backlog Produit et son évolution restent bien visibles.

Le Product Owner, en choisissant ce que l’Equipe de Développement devrait ensuite faire et ce qui peut être reporté à plus tard, gère le périmètre en fonction du calendrier pour sortir le meilleur produit possible.

Le Product Owner produit une liste ordonnée et priorisée de ce qui doit être réalisé.

Scrum Master

Le ScrumMaster est un « leader au service de l’équipe » (servant leader), qui aide le reste de l’Equipe Scrum à suivre le processus.

Le ScrumMaster doit avoir une bonne compréhension du cadre de travail Scrum et la capacité de former les autres personnes à ses subtilités.

Le ScrumMaster travaille avec le Product Owner pour l’aider à comprendre comment créer et maintenir le Backlog Produit.

Il travaille avec l’Equipe de Développement pour découvrir et mettre en oeuvre les pratiques d’ingénierie nécessaires pour réussir à finir chaque Sprint.

Il travaille avec l’Equipe Scrum entière pour faire évoluer la Définition du Fini (Definition of Done).

Une autre responsabilité du ScrumMaster est de s’assurer que les obstacles à la progression de l’équipe sont supprimés. Ces obstacles peuvent être externes à l’équipe, par exemple le manque de soutien d’une autre équipe, ou internes, par exemple le Product Owner ne sait pas comment correctement préparer le Backlog Produit.

Le ScrumMaster favorise l’auto-organisation. Les problèmes doivent être résolus par l’équipe autant que possible.

Le ScrumMaster agit comme un coach pour l’Equipe Scrum, en l’aidant à dérouler le processus Scrum. Il aide ses membres à travailler ensemble et à apprendre le cadre de travail Scrum, et il les protège des perturbations internes et externes. Il peut faciliter les réunions, et aider l’Equipe Scrum à rester sur la bonne voie, productive et apprenante.

Le ScrumMaster est responsable du fait que Scrum soit compris et en place, à l’intérieur et à l’extérieur de l’équipe. Il aide les personnes en dehors de l’équipe à comprendre le processus, et identifie les interactions qui aident ou non l’équipe.

Le ScrumMaster aide chaque personne à s’améliorer pour que l’Equipe Scrum devienne plus productive et produise de plus en plus de valeur (valuable).

Development Team / Membre de l ’Equipe de Développement

« Développeur » =  toute personne qui travaille à la création du produit.

L’Equipe de Développement est responsable de déterminer la quantité de travail qu’elle peut réaliser lors d’un Sprint et de produire un Incrément utilisable lors de chaque Sprint.

L’Equipe de Développement est composée de professionnels qui travaillent pour fournir l’Incrément Produit. Ses membres s’auto-organisent pour accomplir le travail.

Les membres de l’Equipe de Développement doivent être disponibles à plein temps sur le projet. Scrum exige que l’Equipe de Développement soit un groupe pluridisciplinaire de personnes qui dispose en son sein de toutes les compétences nécessaires pour livrer chaque Incrément Produit.

Les membres de l’Equipe de Développement ont la responsabilité de s’auto-organiser pour atteindre l’objectif du Sprint, en produisant chaque nouvel Incrément Produit en fonction de chaque Plan de Sprint.

Les membres de l’Equipe de Développement prévoient ce qu’ils peuvent réaliser dans un Sprint, et ils décident comment ils vont le faire.

L’Equipe Scrum (Scrum Team)

Ainsi l’équipe scrum ou Scrum Team est composée du Product Owner, du Scrum Master et de la Development Team.

Evidemment, le Product Owner n’est pas l’unique responsable pour tout. Toute l’Equipe Scrum porte la responsabilité d’être aussi productive que possible, d’améliorer ses pratiques, de poser les bonnes questions et d’aider le Product Owner …

C’est bien pourquoi, on parle d’Equipe Scrum.

Le cadre de travail Scrum / Le « Framework » Scrum

Scrum est un cadre de travail (framework) utilisé pour mettre au point un produit.

Scrum commence lorsque différentes parties prenantes (stakeholders) ont besoin d’un certain produit.

Scrum est un processus d’équipe. L’équipe Scrum comprend trois rôles : le Product Owner, le ScrumMaster et les membres de l’Equipe de Développement.

Product Owner

Le Product Owner a la responsabilité de décider du travail à réaliser et d’en décider les priorités.

Scrum Master

Le ScrumMaster agit en tant que leader et facilitateur au service de l’équipe (servant leader) en aidant l’équipe et l’organisation à faire le meilleur usage de Scrum.

Team Members

L’Equipe de Développement fabrique le produit de manière incrémentale avec une série de courtes périodes de temps appelées Sprints.

Les sprints

Scrum procède par des itérations appelées « Sprint(s) ».

Un Sprint est une période de temps fixe, de une à quatre semaines, avec une préférence pour les intervalles les plus courts.

A chaque Sprint, l’Equipe Scrum fabrique et livre un Incrément Produit (Product Increment).

L’incrément Produit (Product Increment)

Chaque incrément est identifiable, démontre une amélioration, exécute un sous-ensemble du produit, satisfait des critères d’acceptation partagés et respecte un niveau de qualité appelé « Définition du Fini » (Definition of Done).

L’Incrément Produit est le résultat attendu à l’issue de chaque Sprint.

Il s’agit d’une version intégrée du produit, avec un niveau de qualité qui lui permet d’être déployable à la demande par le Product Owner.

Scrum et ses artéfacts

Scrum comprend trois artefacts essentiels, le Backlog Produit (Product Backlog), le Backlog du Sprint (Sprint Backlog), et l’Incrément Produit

Product Backlog

Le Backlog Produit est une liste ordonnée d’idées pour le produit, que l’on maintient dans l’ordre de fabrication attendu.

Sprint Backlog

Le Backlog du Sprint constitue le plan détaillé du développement au sein du prochain Sprint.

 Product Increment

L’Incrément Produit est le résultat attendu à l’issue de chaque Sprint.

L’incrément  constitue la portion de produit potentiellement livrable.

Scrum et la transparence

En plus de ces artefacts, Scrum exige de la transparence au sein de l’équipe et avec les parties prenantes (stakeholders).

Ainsi, l’Equipe Scrum visualise les plans et l’état d’avancement.

Scrum comprend cinq réunions ou cérémonies (events) :

– Le Raffinement du Backlog Produit (Product Backlog Refinement)

– La Planification du Sprint (Sprint Planning)

– La Mêlée Quotidienne (Daily Scrum)

– La Revue de Sprint (Sprint Review)

– La Rétrospective de Sprint (Sprint Retrospective)

Les indicateurs

Les Indicateurs sont nécessaires pour rendre visible la Progression, Scrum requiert de la transparence au sein de l’équipe et à l’extérieur de l’équipe.

Même si l’Incrément produit est le moyen le plus important pour créer de la transparence, l’Equipe Scrum créera tout autre élément nécessaire pour s’assurer que le statut du projet est connu.

Généralement, ces éléments supplémentaires se composent de burn charts et de tableaux de tâches (tasks boards).

Le flux du cycle Scrum

Le cycle Scrum se répète à l’identique pour chaque Sprint. Pour résumer, les membres de l’Equipe Scrum (le Product Owner, l’Equipe de Développement et le ScrumMaster) collaborent pour créer une série d’Incréments Produit, sur des intervalles de temps fixes de courte durée, appelés des Sprints.

Chaque Incrément répond aux critères d’acceptation du Product Owner et l’équipe partage la « Définition du Fini ».

Ils travaillent à partir d’un Backlog Produit.

Au sein de chaque Sprint, l’équipe commence par la Planification du Sprint pour produire le Backlog du Sprint et un Plan pour le Sprint.

Les membres de l’équipe s’auto-organisent pour mener le développement, en utilisant les Mêlées Quotidiennes pour se coordonner et veiller à ce qu’ils produisent le meilleur Incrément Produit possible.

Ils terminent tout d’abord le Sprint par la Revue de Sprint en examinant le produit. Ils effectuent un Raffinement du Backlog Produit pour préparer les prochaines Réunions de Planification de Sprints.

Ils terminent vraiment le Sprint avec la Rétrospective de Sprint en examinant le processus et la dynamique d’Equipe.

Les valeurs de Scrum

L’ensemble du travail à réaliser dans le cadre de Scrum nécessite un ensemble de valeurs acceptées par tous et qui vont servir de fondamentaux pour l’équipe, que ce soit dans ses principes ou dans sa manière de travailler.

A travers l’esprit d’équipe et l’amélioration continue, Scrum fait non seulement émerger ces valeurs mais repose sur elles.

Les 5 valeurs Scrum :

– Focus

Parce que nous sommes concentrés et focalisés, nous travaillons uniquement sur peu de choses à la fois, nous travaillons effectivement tous ensemble et nous produisons un résultat de qualité.

Par conséquent nous livrons de la valeur plus tôt.

– Courage

Nous ne sommes pas seuls et nous sentons que nous avons le support nécessaire, ce qui nous donne plus de ressources à notre disposition.

Cela nous donne le courage de relever de plus grands défis.

– Ouverture

Lors de notre travail d’équipe, nous nous renvoyons du feedback, non seulement sur comment on se sent, mais également sur ce qui gêne notre travail.

Nous apprenons ainsi, par la pratique, qu’il est bon d’exprimer nos préoccupations, ainsi elles peuvent être traitées.

– Engagement

Vu que nous avons un grand contrôle sur notre destin, nous devenons plus déterminés à réussir.

– Respect

Travaillant ensemble, partageant les succès et les échecs, nous en venons à nous respecter les uns les autres et à devenir nous-mêmes dignes de respect.

Si les membres d’une organisation laissent Scrum agir, ils découvriront les avantages de Scrum et commenceront à comprendre pourquoi ces valeurs sont à la fois requises par Scrum, et engendrées par Scrum.

Les principes de Scrum

Scrum est le cadre de travail (framework) Agile le plus connu. Scrum est à l’origine d’une grande partie de la réflexion inhérente aux valeurs et principes du Manifeste Agile, qui représente une base commune pour toutes les approches Agile.

Pour plus d’informations, référez-vous au « Manifeste pour le développement Agile de logiciels ».
Les valeurs du Manifeste Agile s’appliquent directement à Scrum, à savoir:

– Les individus et leurs interactions plus que les processus et les outils

Scrum, comme les autres cadres de travail et méthodes Agile, repose directement sur le fait de faire confiance aux équipes, de faire confiance aux personnes au sein de l’équipe et sur la manière dont elles interagissent.

Les équipes déterminent ce qui doit être fait, comment le faire, et ensuite le font.

Les équipes identifient leurs obstacles, ce qui les ralentissent et prennent la responsabilité de résoudre les difficultés liées au périmètre de leur projet.

Les équipes travaillent avec les autres services de l’organisation pour régler des problèmes sur lesquels elles n’ont pas le contrôle.

C’est essentiel.

Essayer Scrum sans mettre d’abord l’accent sur la responsabilité d’équipe mène généralement à des problèmes d’adoption de la méthode.

– Des logiciels opérationnels plus qu’une documentation exhaustive.

A la fin de chaque Sprint, Scrum exige un incrément produit qui soit fonctionnel et complètement terminé.

Bien entendu différentes activités devront être réalisées : analyse, conception, tests et documentation.

Mais c’est le logiciel opérationnel qui doit permettre à l’organisation de faire du projet un succès.

C’est absolument critique, les équipes Scrum doivent produire un incrément produit à chaque sprint.

– La collaboration avec les clients plus que la négociation contractuelle

Le Product Owner est le principal point de contact pour l’équipe Scrum en ce qui concerne les contacts avec les éventuels utilisateurs finaux du produit, et avec les différents services de l’organisation qui ont besoin d’utiliser le produit qui va être créé.

Le Product Owner est un membre de l’équipe à part entière, et travaille en collaboration avec les différents membres afin de déterminer ce qui doit être fait.

Lors de ce travail collaboratif, le Product Owner sélectionne les choses sur lesquelles l’équipe va travailler prochainement.

Pour cette sélection il s’assure de prendre uniquement en compte les choses qui vont amener la plus grande valeur ajoutée au produit et ce, à n’importe quel moment du projet.

Une fois encore, ce point est critique, le Product Owner se doit de créer une collaboration fructueuse avec les équipes dont il fait partie.

– L’adaptation au changement plus que le suivi d’un plan

Tout dans Scrum a été conçu afin de s’assurer que chacun a le niveau d’information nécessaire pour prendre les bonnes décisions concernant le projet.

Le progrès du projet est représenté par un incrément produit qui existe et qui fonctionne.

Le backlog des choses à réaliser est disponible et visible par tous.

L’avancement global du projet ainsi que la progression sprint par sprint est clairement visible.

Les problèmes ou les risques sont discutés en toute transparence et traités immédiatement.

Une fois de plus, ceci est critique, Scrum fonctionne bien pour les équipes qui vérifient en toute transparence ce qui se passe réellement sur le projet et adaptent leurs actions à la réalité.

Scrum fonctionne mal pour ceux qui n’appliquent pas ce principe.

Test certification Scrum (5 questions)

Question 1
Line in the Agile Manifesto reads, « ____________ over following a plan ». Please select which option best completes the statement.

A. Communicating frequently

B. Completing requirements

C. Asking the customer

D. Responding to change

Question 2
_____________ can change the priority of items in the _________ backlog at any time.

A. The Product Owner(s); Sprint

B. The Team; Product

C. The Product Owner(s); Product

D. The Scrum Master; Sprint

Question 3
________________ constitute the Sprint Backlog and are often estimated in hours.
A. Stories

B. Use Cases

C. Features

D. Tasks

Question 4
_________________ is an agile development methodology which is intended to improve software quality and responsiveness to changing customer requirements by executing frequent « releases » in short development cycles (timeboxing), by programming in pairs or conducting extensive code reviews, by unit testing all code, and by maintaining a flattened management structure.
A. Scrum

B. Lean

C. Agile Modelling

D. XP

Question 5

A _____________________ is created during the first half of the Sprint planning meeting and a _________________ is created during the second half of the Sprint planning meeting?

A. Sprint Backlog, collection of tasks

B. Product Backlog, collection of tasks

C. Sprint Goal, Sprint Backlog

D. Product Backlog, Sprint Backlog

Answers here:

https://alecoledelavie.com/accueil/?p=1393

Test certification Scrum (5 questions and answers)

Question 1
Line in the Agile Manifesto reads, « ____________ over following a plan ». Please select which option best completes the statement.

A. Communicating frequently

B. Completing requirements

C. Asking the customer

D. Responding to change

Answer: D

Summary
A line in the Agile Manifesto reads, « ____________ over following a plan ». This is intended to mean that agile development is highly adaptive and focused on quick responses to change and continuous development.

Question 2
_____________ can change the priority of items in the _________ backlog at any time.

A. The Product Owner(s); Sprint

B. The Team; Product

C. The Product Owner(s); Product

D. The Scrum Master; Sprint

Answer: C

Summary
The Product Owner(s) can change the priority of items in the Product backlog at any time. The Product Backlog is continuously updated by the Product Owner(s) to reflect changes in the needs of the customer.

Question 3
________________ constitute the Sprint Backlog and are often estimated in hours.
A. Stories

B. Use Cases

C. Features

D. Tasks

Answer: D

Summary
Tasks constitute the Sprint Backlog and are often estimated in hours. Alternate choices: Use cases are used for either requirements. A task may be to create use cases. Stories, also known as Storycards, are what may be used to document the product backlog item. Features requested by Product Owners are generally expressed in the Product Backlog as one or more storycards.

Question 4
_________________ is an agile development methodology which is intended to improve software quality and responsiveness to changing customer requirements by executing frequent « releases » in short development cycles (timeboxing), by programming in pairs or conducting extensive code reviews, by unit testing all code, and by maintaining a flattened management structure.
A. Scrum

B. Lean

C. Agile Modelling

D. XP

Answer: D

Summary
Extreme Programming is an agile development methodology which is intended to improve software quality and responsiveness to changing customer requirements by executing frequent « releases » in short development cycles (timeboxing), by programming in pairs or conducting extensive code reviews, by unit testing all code, and by maintaining a flattened management structure

Question 5

A _____________________ is created during the first half of the Sprint planning meeting and a _________________ is created during the second half of the Sprint planning meeting?

A. Sprint Backlog, collection of tasks

B. Product Backlog, collection of tasks

C. Sprint Goal, Sprint Backlog

D. Product Backlog, Sprint Backlog

Answer: C

Summary
A Sprint Goal is created during the first half of the Sprint planning meeting and a Sprint Backlog is created during the second half of the Sprint planning meeting

Test certification scrum (16 questions)

1) What kind of software development projects can be executed by Scrum Project Management Framework?

Choice-1: Complete software packages

Choice-2: Customer projects

Choice-3: Sub-systems, components or parts of bigger systems

Choice-4: All kinds of software development projects

Choice-5: None of the given answers

2) What does NOT belong to cornerstones of the agile manifesto?

Choice-1: Individuals and interactions over processes and tools

Choice-2: Working software over comprehensive documentation

Choice-3: Processes over people

Choice-4: Customer collaboration over contract negotiation

Choice-5: Responding to change over following a plan

4) What is defined by the Scrum Framework?

A) Rules & Roles

B) Document guidelines

C) Artifacts and events

Choice-1: A

Choice-2: B

Choice-3: C

Choice-4: A, B, C

Choice-5: A, C

5) Where are the customer requirements stored?

Choice-1: In the Product Backlog

Choice-2: In the Sprint Backlog

Choice-3: In a database

Choice-4: In a Scrum Product Requirement Specification

Choice-5: Nowhere. The Scrum Product Owner knows them

6) Which ones of the following main roles are defined by Scrum Framework?

A) Scrum Tester

B) The Scrum Team

C) Scrum Manager

D) Scrum Master

E) Scrum Product Owner

Choice-1: A, B, C, D, E

Choice-2: B, C, D, E

Choice-3: B, D, E

Choice-4: A, B, D, E

Choice-5: A, B, C, D

7.      Which technique is a productive method for the ScrumMaster to use to help facilitate communication between the Team and Product Owner?

A.     Teach the team to talk in terms of business needs and objectives

B.     Teach the Product Owner about the technologies employed during the Sprints

C.     Facilitate collaborative meetings between them

D.     All of these

8.      What are the three components of an empirical process?

A.     Feedback, courage, and simplicity

B.     Planning, taking action, and checking for quality

C.     Planning, committing, and measuring

D.     Transparency, inspection, and adaptation

9.      After a Team has committed to a Sprint goal, what authority does it have?

A.     The team has authority to swap Sprint backlog items with Product Backlog items if it cannot finish them

B.     The team works according to the priorities set by the ScrumMaster, as the ScrumMaster is committed to the Scrum Framework.

C.     The Team does whatever is necessary to achieve the goal.

D.     The Team works under the authority of the Product Architect, who has set the definition of done.

10.      Once a team starts a Sprint, who determines how the team does its work?

A.     Team lead

B.     Project Manager

C.     ScrumMaster

D.     Team

11.      Which statement is accurate about the role of the Product Owner during the Daily Scrum?

A.     The Product Owner ensures the Burndown rate is maintained at the estimated rate.

B.     The Product Owner’s participation is defined by the Team.

C.     The Product owner outlines the additional changes that must be absorbed by the team in Sprint

D.     The Product Owner provides instruction to the Team on how to implement a workable solution.

12.      What happens if, during a sprint, the Product Owner identifies a new, important Product Backlog item (PBI)?

A.     The ScrumMaster encourages the Team to include the extra item

B.     The Team works overtime to finish the PBI in the current sprint

C.     The Product Owner adds the new PBI to the Product Backlog

D.     The team extends the Sprint duration to include the new item

13.      If a Team member is consistently late for the Daily Scrum, what is usually the first thing a team should do?

A.     Report the Team member to his or her manager

B.     Meet with the Team member to determine a solution

C.     Have the Team member do the testing

D.     Ask the ScrumMaster to move the Team member off the Team.

14.      Why should the Product Owner attend the Daily Scrum?

A.     To tell the Team which tasks to work on next and update the Product Backlog

B.     To make sure the Team is still on target for its Sprint goals

C.     To comment on the Team’s progress

D.     To see the progress being made and determine whether the team needs help

15.      During a Daily Scrum meeting, Olivia mentions she has found some open source code she thinks will solve one of the problems she has been working on. She wants to implement it immediately. What is the best next step?

A.     After the Daily Scrum meeting is held, a separate meeting is conducted to discuss the open source solution

B.     All members of the Team are told to evaluate Olivia’s solution and report back to the team at the next Daily Scrum meeting

C.     The Product Owner notes the impediment and solves the problem after the meeting.

D.     The ScrumMaster tells Olivia to prepare an example and presentation for the Team so they can consider using the code.

16.      Who is primarily responsible for ensuring that everyone follows Scrum rules and practices?

A.     The ScrumMaster

B.     Each individual developer

C.     All Team members collectively

D.     The Product Owner

Answers here:

https://alecoledelavie.com/accueil/?p=1388

Test certification scrum (16 questions and answers)

1) What kind of software development projects can be executed by Scrum Project Management Framework?

Choice-1: Complete software packages

Choice-2: Customer projects

Choice-3: Sub-systems, components or parts of bigger systems

Choice-4: All kinds of software development projects

Choice-5: None of the given answers

Answer : 4 All kinds of software development projects

2) What does NOT belong to cornerstones of the agile manifesto?

Choice-1: Individuals and interactions over processes and tools

Choice-2: Working software over comprehensive documentation

Choice-3: Processes over people

Choice-4: Customer collaboration over contract negotiation

Choice-5: Responding to change over following a plan

Answer : 3: Processes over people

4) What is defined by the Scrum Framework?

A) Rules & Roles

B) Document guidelines

C) Artifacts and events

Choice-1: A

Choice-2: B

Choice-3: C

Choice-4: A, B, C

Choice-5: A, C

Answer : 5 / A, C

5) Where are the customer requirements stored?

Choice-1: In the Product Backlog

Choice-2: In the Sprint Backlog

Choice-3: In a database

Choice-4: In a Scrum Product Requirement Specification

Choice-5: Nowhere. The Scrum Product Owner knows them

Answer : 1 / In the Product Backlog

6) Which ones of the following main roles are defined by Scrum Framework?

A) Scrum Tester

B) The Scrum Team

C) Scrum Manager

D) Scrum Master

E) Scrum Product Owner

Choice-1: A, B, C, D, E

Choice-2: B, C, D, E

Choice-3: B, D, E

Choice-4: A, B, D, E

Choice-5: A, B, C, D

Answer : 3

7.      Which technique is a productive method for the ScrumMaster to use to help facilitate communication between the Team and Product Owner?

A.     Teach the team to talk in terms of business needs and objectives

B.     Teach the Product Owner about the technologies employed during the Sprints

C.     Facilitate collaborative meetings between them

D.     All of these
Answer : D

8.      What are the three components of an empirical process?

A.     Feedback, courage, and simplicity

B.     Planning, taking action, and checking for quality

C.     Planning, committing, and measuring

D.     Transparency, inspection, and adaptation

Answer : D

9.      After a Team has committed to a Sprint goal, what authority does it have?

A.     The team has authority to swap Sprint backlog items with Product Backlog items if it cannot finish them

B.     The team works according to the priorities set by the ScrumMaster, as the ScrumMaster is committed to the Scrum Framework.

C.     The Team does whatever is necessary to achieve the goal.

D.     The Team works under the authority of the Product Architect, who has set the definition of done.

Answer : C

10.      Once a team starts a Sprint, who determines how the team does its work?

A.     Team lead

B.     Project Manager

C.     ScrumMaster

D.     Team

Answer : D

11.      Which statement is accurate about the role of the Product Owner during the Daily Scrum?

A.     The Product Owner ensures the Burndown rate is maintained at the estimated rate.

B.     The Product Owner’s participation is defined by the Team.

C.     The Product owner outlines the additional changes that must be absorbed by the team in Sprint

D.     The Product Owner provides instruction to the Team on how to implement a workable solution.

Answer : B

12.      What happens if, during a sprint, the Product Owner identifies a new, important Product Backlog item (PBI)?

A.     The ScrumMaster encourages the Team to include the extra item

B.     The Team works overtime to finish the PBI in the current sprint

C.     The Product Owner adds the new PBI to the Product Backlog

D.     The team extends the Sprint duration to include the new item
Answer : C

13.      If a Team member is consistently late for the Daily Scrum, what is usually the first thing a team should do?

A.     Report the Team member to his or her manager

B.     Meet with the Team member to determine a solution

C.     Have the Team member do the testing

D.     Ask the ScrumMaster to move the Team member off the Team.

Answer : B

14.      Why should the Product Owner attend the Daily Scrum?

A.     To tell the Team which tasks to work on next and update the Product Backlog

B.     To make sure the Team is still on target for its Sprint goals

C.     To comment on the Team’s progress

D.     To see the progress being made and determine whether the team needs help

Answer : D

15.      During a Daily Scrum meeting, Olivia mentions she has found some open source code she thinks will solve one of the problems she has been working on. She wants to implement it immediately. What is the best next step?

A.     After the Daily Scrum meeting is held, a separate meeting is conducted to discuss the open source solution

B.     All members of the Team are told to evaluate Olivia’s solution and report back to the team at the next Daily Scrum meeting

C.     The Product Owner notes the impediment and solves the problem after the meeting.

D.     The ScrumMaster tells Olivia to prepare an example and presentation for the Team so they can consider using the code.

Answer : A

16.      Who is primarily responsible for ensuring that everyone follows Scrum rules and practices?

A.     The ScrumMaster

B.     Each individual developer

C.     All Team members collectively

D.     The Product Owner

Answer : A

Test certification Scrum (30 questions)

1. _____ In Scrum, tracking hours is a good way to get better at estimation.
A-True
B-False

2. _____ “Self-organizing” means that it is okay for one team member to do nothing for a whole day.
A-True
B-False

3. _____ If a team is missing a critical skill, it is important to add a person to the team as soon as possible.
A-True
B-False

4. _____ Scrum works, but works poorly, for teams doing maintenance and bug fixing.
A-True
B-False

5. _____ The best size for a Scrum team is seven people.
A-True
B-False

6. _____ The Product Owner cannot change the effort estimate on a Product Backlog Item.
A-True
B-False

7. _____ A Product Backlog Item must absolutely be expressed as a User Story and this is an official part of Scrum.
A-True
B-False

8. _____ A “Done-Done” product means potentially shippable.
A-True
B-False

9. _____ Potentially shippable product increment means that the decision of shipping is strictly a business decision.
A-True
B-False

10. _____ The team commits to deliver the Sprint Backlog and it is the only thing that matters.
A-True
B-False

11. _____ One benefit of the team doing estimation together is to gain a similar understanding of the Product Backlog Items.
A-True
B-False

12. _____ The Product Owner is empowered to punish the team if it fails its sprint commitment.
A-True
B-False

13. _____ Product Backlog Items ideally should be broken into tasks that are less than one day because it helps for transparency.
A-True
B-False

14. _____ It is OK to make a Sprint length longer than usual as long as the Sprint backlog items are delivered.
A-True
B-False

15. _____ The ScrumMaster assigns the tasks to the Team Members.
A-True
B-False

16. _____ The team reports to the ScrumMaster on the 3 questions of the Daily Scrum.
A-True
B-False

17. _____ The ScrumMaster only has authority on the Scrum process but no authority on the people in the team.
A-True
B-False

18. _____ The retrospective is about inspection and adaptation on the Scrum process only.
A-True
B-False

19. A functional manager that is part of a Scrum team should _________  the boss of another team member.
A- Be
B- Not be

20. The ScrumMaster is responsible for removing _____________ for the Scrum Team.
A-User stories
B-Hours
C-Obstacles

21. The Product Owner is responsible for maximizing ________ for the business.
A-Time
B-Cost
C-ROI

22. The Team Members are responsible for doing the ________ in the Sprint backlog.
A-Tasks
B-User Stories

23. A Scrum team normally does ____-____ Product Backlog Items every Sprint.
A-5-10
B-10-15
C-15-20

24. A _______-week long Sprint is often best in software product
A-3
B-5

25. The Product Owner is responsible for “what” needs to be built, not “how”. The ScrumMaster is responsible for…
A- “how” the product is built
B- “how” the team uses Agile tools such as “Planning Poker”
C- results
D- the happiness of the team members doing their work

26. Which of the following is true about the Daily Scrum?
A- The ScrumMaster is not allowed to be at the Daily Scrum
B- Each resource on the team answers three questions during the Daily Scrum
C- The Daily Scrum lasts at least 15 minutes
D- It’s okay for the Daily Scrum to not be daily (e.g. every two days)

27. In the second part of the Sprint Planning meeting:
A- the Product Owner plays an active role in breaking the tasks
B- the Product Owner clarifies the stories when need be
C- the ScrumMaster leads the task breaking activity because he is the technical leader
D- Team Members make UML diagrams of all the requirements and create the tasks once the meeting is finished
E- not all Team members need to be present at this meeting.

28. During the Sprint review:
A- the Product Owner discovers and evaluates the potentially shippable software made by the team
B- the Scrum Team demonstrates the product increment, preferably to other stakeholders, and gets feedback to improve the product
C- the Team Members must do a PPT presentation explaining what they have built
D- the most important activity in this meeting is to make sure that we are on track and that we will hit the release date

29. Which of the following statements about velocity is true.
A- velocity is a measure of productivity: the higher velocity the better
B- conformance to a standard velocity should be tracked and verified
C- velocity allows management to compare teams for performance appraisal purposes
D- velocity is mainly meant for longer term planning

30. The Definition of “Done”:
A- lists the development activities that are done by the team for each Product Backlog Item and Task, Sprint after Sprint
B- should be standardized by management to reach “Done-Done” and all the teams must comply to it
C- shows the current ability of the team
D- should consider all internal and external quality measures to ensure

Answers here:

https://alecoledelavie.com/accueil/?p=1382

Test certification Scrum (30 questions)

1. _____ In Scrum, tracking hours is a good way to get better at estimation.
A-True
B-False

Answer : B

2. _____ “Self-organizing” means that it is okay for one team member to do nothing for a whole day.
A-True
B-False

Answer : A

3. _____ If a team is missing a critical skill, it is important to add a person to the team as soon as possible.
A-True
B-False

Answer : B

4. _____ Scrum works, but works poorly, for teams doing maintenance and bug fixing.
A-True
B-False

Answer : A

5. _____ The best size for a Scrum team is seven people.
A-True
B-False

Answer : B

6. _____ The Product Owner cannot change the effort estimate on a Product Backlog Item.
A-True
B-False

Answer : A

7. _____ A Product Backlog Item must absolutely be expressed as a User Story and this is an official part of Scrum.
A-True
B-False

Answer : B

8. _____ A “Done-Done” product means potentially shippable.
A-True
B-False

Answer : A

9. _____ Potentially shippable product increment means that the decision of shipping is strictly a business decision.
A-True
B-False

Answer : A

10. _____ The team commits to deliver the Sprint Backlog and it is the only thing that matters.
A-True
B-False

Answer : B

11. _____ One benefit of the team doing estimation together is to gain a similar understanding of the Product Backlog Items.
A-True
B-False

Answer : A

12. _____ The Product Owner is empowered to punish the team if it fails its sprint commitment.
A-True
B-False

Answer : B

13. _____ Product Backlog Items ideally should be broken into tasks that are less than one day because it helps for transparency.
A-True
B-False

Answer : A

14. _____ It is OK to make a Sprint length longer than usual as long as the Sprint backlog items are delivered.
A-True
B-False

Answer : B

15. _____ The ScrumMaster assigns the tasks to the Team Members.
A-True
B-False

Answer : B

16. _____ The team reports to the ScrumMaster on the 3 questions of the Daily Scrum.
A-True
B-False

Answer : B

17. _____ The ScrumMaster only has authority on the Scrum process but no authority on the people in the team.
A-True
B-False

Answer : A

18. _____ The retrospective is about inspection and adaptation on the Scrum process only.
A-True
B-False

Answer : B

19. A functional manager that is part of a Scrum team should _________  the boss of another team member.
A- Be
B- Not be

Answer : B

20. The ScrumMaster is responsible for removing _____________ for the Scrum Team.
A-User stories
B-Hours
C-Obstacles

Answer : C

21. The Product Owner is responsible for maximizing ________ for the business.
A-Time
B-Cost
C-ROI

Answer : C

22. The Team Members are responsible for doing the ________ in the Sprint backlog.
A-Tasks
B-User Stories

Answer : A

23. A Scrum team normally does ____-____ Product Backlog Items every Sprint.
A-5-10
B-10-15
C-15-20

Answer : A

24. A _______-week long Sprint is often best in software product
A-3
B-5

Answer : A

25. The Product Owner is responsible for “what” needs to be built, not “how”. The ScrumMaster is responsible for…
A- “how” the product is built
B- “how” the team uses Agile tools such as “Planning Poker”
C- results
D- the happiness of the team members doing their work

Answer : D

26. Which of the following is true about the Daily Scrum?
A- The ScrumMaster is not allowed to be at the Daily Scrum
B- Each resource on the team answers three questions during the Daily Scrum
C- The Daily Scrum lasts at least 15 minutes
D- It’s okay for the Daily Scrum to not be daily (e.g. every two days)

Answer : B

27. In the second part of the Sprint Planning meeting:
A- the Product Owner plays an active role in breaking the tasks
B- the Product Owner clarifies the stories when need be
C- the ScrumMaster leads the task breaking activity because he is the technical leader
D- Team Members make UML diagrams of all the requirements and create the tasks once the meeting is finished
E- not all Team members need to be present at this meeting.

Answer : B

28. During the Sprint review:
A- the Product Owner discovers and evaluates the potentially shippable software made by the team
B- the Scrum Team demonstrates the product increment, preferably to other stakeholders, and gets feedback to improve the product
C- the Team Members must do a PPT presentation explaining what they have built
D- the most important activity in this meeting is to make sure that we are on track and that we will hit the release date

Answer : B

29. Which of the following statements about velocity is true.
A- velocity is a measure of productivity: the higher velocity the better
B- conformance to a standard velocity should be tracked and verified
C- velocity allows management to compare teams for performance appraisal purposes
D- velocity is mainly meant for longer term planning

Answer : D

30. The Definition of “Done”:
A- lists the development activities that are done by the team for each Product Backlog Item and Task, Sprint after Sprint
B- should be standardized by management to reach “Done-Done” and all the teams must comply to it
C- shows the current ability of the team
D- should consider all internal and external quality measures to ensure

Answers : A, B