Doc fonctionnelle : décrit le quoi et le pourquoi (point de vue utilisateur / chef de projet).
En fin de sprint, une partie des items ne passera pas et doit être reportée. Jusqu'ici il fallait, pour chaque item, ouvrir la modale « Changer de sprint » et retrouver le bon sprint dans la liste — alors que la réponse est presque toujours la même : le sprint d'après.
L'action « Prochain sprint » fait ce geste en deux clics, sans avoir à savoir quel sprint est le suivant.
Un message de confirmation rappelle le sprint dans lequel l'item a atterri.
Les sprints du projet sont classés par date de début (date réelle si elle est saisie, sinon date prévisionnelle). Le sprint proposé est le premier qui commence après le sprint actuel de l'item.
| Situation de l'item | Sprint proposé |
|---|---|
| Rattaché à un sprint daté | Le premier sprint qui commence après lui |
| Rattaché à aucun sprint | Le premier sprint à venir (début postérieur à aujourd'hui) |
| Rattaché à un sprint sans date | Idem : le premier sprint à venir |
Les sprints sans aucune date ne sont jamais proposés : ils ne sont pas positionnables dans le temps. C'est aussi le tri par date — et non l'ordre alphabétique du board — qui fait foi : sur un projet où des sprints « au long cours » (R&D, chantiers annuels) cohabitent avec les sprints mensuels, la confirmation nomme le sprint retenu pour lever toute ambiguïté avant de valider.
Cocher les lignes puis utiliser l'action en masse « Changer de sprint », qui laisse choisir le sprint de destination. « Prochain sprint » reste une action unitaire, volontairement sans saisie.