SPRINT/ITERATION PLANNING

The purpose of Sprint/Iteration Planning is for a team to identify and commit to the total amount of work they think they can to accomplish within a 2 week period. In order to have a successful Sprint Planning meeting, there needs to be an organized, prioritized backlog with a sufficient amount of stories in a READY state for the team to pick up and complete within the iteration. A typical Sprint Planning meeting proceeds as follows.

• The Team, Scrum master, and Product Owner examine the current state of the backlog together and look at the following:
  • Have any stories been carried over since last Sprint?
  • Are any high priority stories blocked?
  • Do we have enough stories in READY state to meet our planning horizon (150% of a team’s Velocity, so if the rolling average of how many story points were completed in the last 3 Sprints is 10, we typically like to have at least 15 points in READY state)?
• The Product Owner reorganizes the stories by priority if anything has changed since the last Sprint planning meeting
• The Product Owner describes each story they would like to see completed, and works together with the team to ensure the Acceptance Criteria are complete and the team feels comfortable delivering what’s described
• The team then commits to a number of User Stories that add up to a number in line with their Velocity average
  • If their Velocity is 10, and they have 3, 3 point stories and the Product Owner asks them to take a 2 pointer for a total of 11, they may choose to agree or disagree based on their collective confidence level
  • If their Velocity is 10 and the Product owner asks for 18 points, the Scrum Master should step in and prevent this. If a team does not have a historical basis for completing that much work, they would be setting themselves up for failure.
  • If a team is new and has no Velocity data, they should take their best guess, observe their results, and plan their next Sprint based on how many points were completed
  • Remember a team can always add work from the backlog if they finish early (that’s why we like to have 150% of a team’s Velocity READY), it’s always better to over deliver than it is to over commit
• After a team has committed to all of the User Stories they plan to deliver in the upcoming Sprint, they can get down to the business of Task Planning. Task planning typically goes as follows:
  • Story by story, the team looks at the Acceptance Criteria, and thinks through the tasks they will have to perform in order to deliver that story in a way that fulfills that criteria
  • Tasks are then added to the story one by one, best practices suggest to size your tasks so you can complete one or 2 a day
  • As each task is added, the person who will be performing the task is asked to estimate how much time they think it will take to accomplish the task
  • The time added to the task is measured in what we call ideal hours, a fun description of ideal hours might be:
    • You have unplugged your phone
    • You have closed your e-mail client
    • You have just used the bathroom
    • You have the perfect amount of caffeine in your system
  • In short, this represents time completely focused on your task without interruptions, so if you have 3 tasks amounting to 8 ideal hours, it’s likely it will take you at least 2 days to finish all 3, unless you pull a 12-14 hour day (which we don’t recommend!)
  • It’s important to note here that we are trying to look at the totality of work we want to accomplish based on the best information we have to date, NOT trying to predict the future, task plans can and should be updated as information changes
  • After all the user Stories are Task planned, the team is then asked if they can commit to the plan. If the answer is yes, you’re DONE!