Le contexte

La mission en tant que product manager se déroule chez Faber & Co Real Estate, une entreprise basée à Londres spécialisée dans la vente de biens immobiliers.

Je suis chargé de mettre à jour le site web existant pour corriger les erreurs et déployer les nouvelles fonctionnalités permettant de répondre aux demandes croissantes des utilisateurs.

Ce que j’ai fait

Le premier sprint s’est concentré sur l'ajout d'une option de recherche parmi les annonces, mais tout n’a pas été livré comme prévu et je décide donc de tester les éléments livrés.

Après quelques tests, je liste dans Trello les différents bugs et crée des tickets en m’appuyant sur la checklist Opquast, je découpe les users stories pour passer les US valides dans la catégorie "Approuvé pour livraison (terminé)" et les US non valide sont reléguées dans la catégorie “En cours”.

Lors de la création du release plan, le premier sprint a été mis à jour pour être plus réaliste et adéquat. Les users stories non terminées ont été redistribuée sur les prochains sprints. J’ai réécris toutes les users stories selon le schéma "Étant donné, quand, alors".

Avec la méthode MoSCoW, j’ai défini les priorités à sortir et exclu certaines US du périmètre, j’ai découpé les US en les regroupant dans des sprints avec un Goal clair et explicite en définissant les stratégies de release adéquat (Beta interne, Canary release, Soft launch…) et les précisions à porter sur certains tickets (spécifications techniques nécessaires, pair programming…).

Enfin la review de sprint présente :

• le travail accompli durant le sprint 1 avec les user stories validées, celles qui ne sont pas validées et les causes ;
• une démonstration du produit et des nouvelles fonctionnalités ;
• les développements à venir sur les prochains sprints avec les modifications prévues (bêta, pair programming, spécifications techniques…).

Livrables

<aside> 📁 Le SprintBoard du sprint 1 mis à jour avec :

• le détail de ce qui est accepté/rejeté, avec vos commentaires et captures d’écran ;
• les 2 (minimum) nouveaux tickets relatifs aux « bugs » et aux dysfonctionnements supplémentaires que vous aurez trouvés en utilisant Opquast ;
• les critères d’acceptation des tickets réécrits selon le schéma rédigé en respectant la formule "Étant donné, quand, alors". </aside>

<aside> 📁 Le planning de release mis à jour suite au premier sprint avec :

• l’ensemble des livraisons que vous avez prévues sur les cinq sprints, et les objectifs pour chacune de ces sorties ;
• les critères d’acceptation pour tous les tickets des sprints à venir réécrits selon le schéma "Étant donné, quand, alors" ;
• un étiquetage sur les tickets nécessitant des stratégies de release particulières dans les sprints à venir (bêta, soft launch, etc.) ;
• un étiquetage sur les tickets nécessitant des spécifications techniques de la part de l’équipe technique ;
• un étiquetage sur les tickets nécessitant d’être traités par deux développeurs travaillant en binôme (pair programming). </aside>

<aside> 📁 Votre review de sprint (de 6 à 12 slides) sous la forme d’une présentation de type PowerPoint ou Canva.

</aside>

Compétences développées