Produit
Mise en situation entretien Product owner
Exemple d'étude de cas pour un entretien de Product owner : l'exercice, la grille, les critères et les erreurs fréquentes.
15 minutes, le même exercice pour chaque candidat, sous contrôle anti-triche.
Exemple d'exercice
Vous êtes un product owner en refinement. Une user story, dit seulement « l'utilisateur veut un tableau de bord ». Trois équipes attendent le découpage pour lundi. On vous demande les stories que vous écrivez et celle que vous sortez du sprint. Contrainte : vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable. Vous avez 15 minutes. Écrivez ce que vous faites, dans quel ordre, ce que vous dites, et ce que vous refusez de promettre.
Grille d'évaluation
| Critère | Insuffisant | Solide | Excellent |
|---|---|---|---|
| Découpage | « Découpage » ignore la personne et le fait : une user story, dit seulement « l'utilisateur veut un tableau de bord ». Trois équipes attendent le découpage pour lundi. | « Découpage » reprend la scène avant toute proposition : une user story, dit seulement « l'utilisateur veut un tableau de bord ». Trois équipes attendent le découpage pour lundi. | « Découpage » sépare, dans cette scène (une user story, dit seulement « l'utilisateur veut un tableau de bord ». Trois équipes attendent le découpage pour lundi), ce qui est sûr de ce qui manque encore. |
| Donnée non fiable écartée | « Donnée non fiable écartée » cède à une user story, ou reste flou, alors que la limite est : vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable. | « Donnée non fiable écartée » tient la limite sans l'arrondir (vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable) et le montre dans les stories que vous écrivez et celle que vous sortez du sprint. | « Donnée non fiable écartée » écrit ce qui est accordé, ce qui est refusé, et pourquoi : vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable. |
| Critère d'acceptation | « Critère d'acceptation » n'adresse pas les stories que vous écrivez et celle que vous sortez du sprint à une user story, ou le remplace par une formule générale. | « Critère d'acceptation » produit les stories que vous écrivez et celle que vous sortez du sprint, adressé à une user story, sans formule générale. | « Critère d'acceptation » met les stories que vous écrivez et celle que vous sortez du sprint en état d'être repris : une user story y lit le geste, la phrase dite et la limite. |
| Ce qui sort du sprint | « Ce qui sort du sprint » s'arrête sans suite, alors qu'une user story attend et que la limite demeure (vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable). | « Ce qui sort du sprint » fixe la suite pour une user story : qui agit, à quel moment, et ce qui reste bloqué. | « Ce qui sort du sprint » ferme le cas avec une user story : ordre des gestes, trace laissée, et la promesse que la limite interdit (vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable). |
Critères
- Découpage
- Donnée non fiable écartée
- Critère d'acceptation
- Ce qui sort du sprint
Erreurs fréquentes
- Laisser la story telle quelle.
- Promettre la marge.
- Écrire des critères que personne ne peut tester.
Une bonne copie
Une bonne copie tranche sous la contrainte (vous n'avez pas le droit de promettre les trois vues, et la donnée de marge n'est pas fiable). Elle produit les stories que vous écrivez et celle que vous sortez du sprint, et l'on comprend ce que la personne ferait dans l'heure qui suit.
Pour le recrutement
Utilisez cette mise en situation pour votre recrutement
CandidAct fait passer cet exercice à chaque candidat Product owner, avec la même grille et un contrôle anti-triche (plein écran, caméra, journal des événements).
Pour les candidats
Entraînez-vous gratuitement à une mise en situation Product owner
La fiche reprend l'exercice et la grille. Elle se télécharge après votre email.