« Comment réaliser le Sprint Planning 2 » : différence entre les versions
De Wiki Agile
Page créée avec « Category: Peter Stevens Category: Portail Planification <div id="content_view" class="wiki" style="display: block"> Auteur : Peter Stevens<br /> Source : [http://... » |
Aucun résumé des modifications |
||
| Ligne 3 : | Ligne 3 : | ||
<div id="content_view" class="wiki" style="display: block"> Auteur : Peter Stevens<br /> Source : [http://www.scrum-breakfast.com/2011/02/how-we-do-sprint-planning-2.html How we do Sprint Planning 2]<br /> Date : 04/02/2011<br /> | <div id="content_view" class="wiki" style="display: block"> Auteur : Peter Stevens<br /> Source : [http://www.scrum-breakfast.com/2011/02/how-we-do-sprint-planning-2.html How we do Sprint Planning 2]<br /> Date : 04/02/2011<br /> | ||
---- | ---- | ||
Traducteur : Fabrice Aimetti<br /> Date : 04/02/2011<br /> | |||
---- | ---- | ||
Traduction :<br /> <br /> | |||
Beaucoup de gens pensent que le Sprint Planning 2 (la seconde mi-temps de la réunion de Sprint Planning) concerne juste la création et l'estimation de la liste des tâches concernant la sélection faite dans le backlog produit. Il s'agit d'une simplification excessive ! Voici une démarche simple pour effectuer une réunion de Sprint Planning 2 efficace.<br /> <br /> Lors du Sprint Planning 1, l'Equipe de développement et le Product Owner négocient les stories qui seront mises en oeuvre dans le sprint à venir. L'équipe s'assure qu'elle comprend bien les stories, en particulier les critères d'acceptation (je recommande de se mettre d'accord sur la question "Comment faire la Démo ?").<br /> <br /> Au cours du Sprint Planning 2, l'Equipe de développement doit trouver une façon de résoudre le problème pris lors du Sprint Planning 1. Cela peut se décomposer en deux parties :<br /> | |||
# La conception de la solution - une conception, une architecture, ... qui explique comment le problème doit être résolu / comment la fonctionnalité doit être réalisée. | # La conception de la solution - une conception, une architecture, ... qui explique comment le problème doit être résolu / comment la fonctionnalité doit être réalisée. | ||
