Plusieurs actions réalisées :
1. Tout d’abord une création des “User stories” et des “Features” qui qualifient le besoin utilisateur.
Une User Story est une description simple d’un besoin utilisateur, du type :
En tant que [utilisateur],
Je veux [fonctionnalité],
Afin de [objectif métier].
Les stories sont organisées par features (ex : sécurité, authentification, paiement, etc.), c’est-à-dire des catégories.
Les US sont divisés en celles “suggérées” et celles “acceptées”. Ici je travaille seule, c’est donc moi qui décide celles acceptées ou non. Il faut considérer un effort à l’US, c’est-à-dire une estimation relative basée sur la complexité globale et non uniquement sur son temps. 
Pour évaluer un effort je me suis basée sur :

Mes connaissances et mon expérience (ce qui engendre la complexité technique)

La complexité fonctionnelle (le rendu pour l’utilisateur)

La dépendance du besoin sur un autre

La quantité et le temps des tests à réaliser 

Par exemple : la création d’une entité (sans relation) serait d’un effort zéro puisqu’elle est automatique sur Symfony et ne demande pas un nombre immense de tests. Tandis que la création du CRUD qui s’ensuit peut-être d’un effort 1 ou 3 suivant le besoin fonctionnel (quels utilisateurs ont accès à ce crud, a-t-on une dépendance avec une autre entité ? etc.)

2. Avec les US et les efforts définis, on peut aller planifier ses sprints en segmentant les missions. 
Quelques exemples de sprints :