Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

What Is A Sprint Planning Meeting

11.663 Aufrufe

Veröffentlicht am

This is a short introduction to the practice of Sprint Planning in Scrum. It would be useful for people new to Scrum or Agile. For more, comment or write to read my blog : http://agilediary.wordpress.com/

Veröffentlicht in: Business, Sport, Technologie
  • Dating for everyone is here: ♥♥♥ http://bit.ly/39mQKz3 ♥♥♥
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Dating direct: ♥♥♥ http://bit.ly/39mQKz3 ♥♥♥
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

What Is A Sprint Planning Meeting

  1. 1. Sprint Planning Meeting An Introduction
  2. 2. Planning Meeting Review Meeting Retrospective SPRINT
  3. 3. What is a Sprint? <ul><li>Sprint in Scrum [or an iteration in a XP team] is a time period (can be anything from 2 to 8 weeks) in which the team does whatever it can to develop software as per the features/ requirements that the Team has committed to . </li></ul><ul><li>The basic mechanics of a sprint in Scrum is centered on it being time boxed to a fixed duration . A 2 week sprint will end in 2 weeks even if all the work the team committed to is not completed. </li></ul>
  4. 4. Why Time Box? <ul><li>A fixed duration, imparts a rhythm to the process . </li></ul><ul><li>The team gets better at identifying how much work to ideally commit to once it keeps working within fixed duration of time </li></ul><ul><li>The team also gets better at doing things within a fixed time period. </li></ul><ul><li>The product owner does not have to wait too long to make a change and trigger happy product owners need to wait at least 1-2 weeks to make changes . </li></ul>
  5. 5. Some More Points <ul><li>There would be no changes in the team composition during the sprint and ideally over many sprints so that team can achieve sustainable pace in working together. </li></ul><ul><li>Product owners [or requirements owners] should be available through out the sprint to explain requirements to the team. </li></ul><ul><li>The team would need someone to help the team surface obstacles, get better, explain Scrum and watch the Scrum/ Agile process. </li></ul><ul><li>Sprint is an Iteration and Increment. </li></ul>
  6. 6. Planning Meeting Review Meeting Retrospective SPRINT
  7. 7. Sprint Planning Meeting <ul><li>A sprint is started with a sprint planning meeting. </li></ul><ul><li>Lets say we are in the first sprint. </li></ul><ul><ul><li>Assuming that there is already a project backlog, picks up “x” number of top priority requirements. </li></ul></ul><ul><ul><li>The “x” requirements are selected through an educated guess. </li></ul></ul><ul><ul><li>The team totals the “relative estimation points” for all these requirements and that becomes the “velocity” of the team for first sprint. </li></ul></ul>
  8. 9. Sprint Planning Meeting <ul><li>The team might need to take on more work [finish all requirements too soon] or need to bump off some requirements [if they find they committed to too much work]. </li></ul><ul><li>The team asks as many questions as possible [acceptance test cases/ test data/ UI designs etc] as they can to the product owner for each requirement and give a final commitment before moving to Part II of the sprint planning session. </li></ul>
  9. 10. Sprint Planning Meeting – Part II <ul><li>They take each requirement and break them into tasks and the team member volunteer, discuss and self assign these tasks. </li></ul><ul><li>Each member should volunteer for as many tasks as possible. </li></ul><ul><li>The estimate is in hours/ quarter days. </li></ul>
  10. 12. Important to Note … <ul><li>The product owner would not coerce the team into committing to more requirements than they feel comfortable with. </li></ul><ul><li>After a few sprints, the teams velocity would be evident. However, the product owner is free to discuss his feedback on whether the team has optimal velocity during sprint review. </li></ul><ul><li>The sprint planning meeting is not the only meeting where product owner needs to be available. </li></ul><ul><li>The sprint planning meeting should be around 2 hours for each week of sprint - 1 hour for discussion on requirements discussion and 1 hour for task breakdown. </li></ul>
  11. 13. Important to Note … <ul><li>Once the team commits to the story - there would be no change: </li></ul><ul><ul><li>no change in development team, </li></ul></ul><ul><ul><li>no change in the requirements and, </li></ul></ul><ul><ul><li>no swapping. </li></ul></ul><ul><li>Clarifications can be provided. </li></ul><ul><li>If the team and product owner is divided on whether it is a change or clarification, it is a change. </li></ul>
  12. 15. Sprint Backlog <ul><li>While a project backlog is a high level description of requirements or features , a sprint backlog is a backlog of specific tasks for a particular sprint . </li></ul><ul><li>Often it is also useful to have each of the tasks relate to a particular requirement. </li></ul>
  13. 18. Sprint Backlog <ul><li>There might be more or less tasks, depending on complexity. </li></ul><ul><li>As the team has not started working on any task, all tasks are pending and work remaining for each of the tasks is as the team has estimated. </li></ul><ul><li>It is important to understand that the team should think of all the tasks it can for each requirement so that the requirement is really done , note it down and estimate it as best as it can and then quickly move to the sprint. </li></ul><ul><li>If the team needs to add a task midway, then the team should definitely do so for each of the requirement. </li></ul>
  14. 19. Sprint Backlog <ul><li>The team members generally volunteer for each of the tasks and in case of a tie, confusion or no ownership, Scrum Master can help the team reach a decision on who does what task. </li></ul><ul><li>During the sprint, often team members would help each other and even swap tasks . </li></ul><ul><li>The sprint backlog would be updated each day and at the end of each day you will know exactly where you are and if you are headed for completing the requirements or not. </li></ul>
  15. 20. During the Sprint
  16. 21. Why Sprint Backlog? <ul><li>It allows them to see where they are and how much work is pending in a sprint </li></ul><ul><li>Provides them focus for working during any given day </li></ul><ul><li>Helps the team self organize by making them coordinate activities daily </li></ul>
  17. 22. Sprint Backlog <ul><li>Sprint backlog is incremental and iterative. </li></ul><ul><li>A sprint backlog is a “team artifact” and they are not obliged to share it with anyone else. </li></ul><ul><li>Sprint backlog promotes teams “self organization”. </li></ul><ul><li>Sprint backlog is “collective”. </li></ul><ul><li>Sprint backlog is “look ahead” at “work remaining” artifact.  </li></ul>
  18. 23. Planning Poker <ul><li>Read a Story </li></ul><ul><li>Everyone shares their estimate </li></ul><ul><li>Diverging estimates discuss </li></ul><ul><li>Repeat </li></ul><ul><ul><li>Team has to agree on estimates </li></ul></ul><ul><ul><li>Surfaces dependencies </li></ul></ul>
  19. 24. Splitting Hard Stories <ul><li>Horizontal Split </li></ul><ul><li>Vertical Split </li></ul>