Introduction

Iteration Planning is different based on the team level framework they are following. In the A2F framework, we discuss 4 methods for Lean | Agile Teams to choose from based on the context of their work.

  1. Scrum
  2. Scrumban
  3. Kanban
  4. XP

We will recap the details for Iteration planning for each method:

Scrum

Sprint Planning. (beginning of each Sprint as early as possible on Day 1).

Attendees: Product Owner, Scrum Master, Implementation Team.

At the beginning of each sprint, a sprint planning meeting must be conducted to determine which Product Backlog items will be completed during the sprint and create the corresponding sub-tasks.

Sprint Planning Input:

  1. Top prioritized Stories from Product Backlog are groomed and meets the Definition of Ready.
  2. All Team members are present (in person or over web conferencing), unless otherwise communicated to the Scrum Master.
  3. Team members should know their own individual capacity for the team prior to Sprint Planning.
  4. Scrum Master displays the Product Backlog on the web conferencing/Projector.

The Sprint Planning ceremony should follow the following guidelines:

  1. For a 2 weeks Sprint, anticipate up to 4 hours for Sprint Planning. Depending on how successful the backlog grooming sessions were will determine how much time you and your team spends in Sprint Planning.
  2. The Scrum Master will perform a capacity analysis by asking the team who will be on PTO, training, etc. and looking at the previous average velocity. The formula is to give each person 8 points per sprint and then subtract 1 point for each day they are not available. A day is further defined as 8 hours. Sprint boundaries are firm. 2 weeks is 2 weeks and capacity analysis is based on the fixed timebox.
  3. Product Owner should be present for the Sprint Planning ceremony with prioritized backlog of Stories. This requires that all User Stories are groomed with Title, Narrative, Description, Acceptance Criteria, and other supporting information as needed.
  4. Product Owner will discuss the sprint goals they would like to accomplish during the sprint and present the prioritized Stories to the team, one at a time, from the top of the backlog. If the story is technical, a spike, or defect, it should be readby someone from the Team. 
  5. Team may ask questions to get clarification on Stories. Details of the story may be updated at this time. Further details of Stories and Sub-Tasks can be discussed during the Sprint, as long as the Team feels confident the Stories will be completed within the Sprint.
  6. If estimation was not done in Backlog Grooming, then the Team estimates the backlog item using the Fibonacci Scale (0, 1, 2, 3, 5, 8, 13, 21, 34, 55…). The Story estimations are based on complexity. Complexity is defined as effort, risks, and unknowns, and is relative to other Backlog items. Therefore, each team should have a baseline story as 1 point, 1 day. When the Team does relative sizing, they are comparing the Story size to the baseline Story. For a Story committed to a Sprint, the Story size should be 8 points or less.
  7. If there is support work that the team will do in the Sprint but it is not known at the time of Sprint Planning, the team can put a Support work item as a Technical Story into their Sprint Commitment and estimate it in points. For example, if the team has a velocity of 40 points and they predict roughly 1/5th of their Sprint will be support work, they can give 8 points for the Support Story and add the tasks once the work is defined in detail.
  8. if there is no support work raised in the current sprint then the team can take equivalent Story points from the backlog.
  9. Sprint commitment will be based on the team’s confidence and velocity. The Scrum Master should facilitate the team discussion for committing.
  10. For remote team members, it is important the Scrum Master has access to a screen sharing service, such as, WebEx to share their screen with the team. If possible, tele-presence is highly recommended. For example, if team members are in Europe and the U.S. – having a tele-presence between Europe and the U.S. helps to unite the team and make them feel more like one team. This also is helpful when doing point estimation.
  11. Once the team initially commits to the Sprint Backlog, the team will break down the Sprint Backlog Items into sub-tasks. Each sub-task should be between 2 to 16 hours and have an assignee (the person that will be doing the work). The estimated hours need to be inputted into the estimate field for that sub-task in JIRA.
    1. If a Story or Sub-Task is dependent on another Team’s backlog, that Story should be linked to their Story as dependency in JIRA and the Scrum Master should help ensure the dependency does not become a blocker.
    2. The Team can use the Sub-Task Breakdown to reconfirm the Sprint Goal(s), verify individual capacity, validate Story estimates, and Sprint commitment.
    3. Please Note: Sub Tasks do not directly correlate to Story Points because points represent complexity. Complexity has 3 parts: Effort, Risks, Unknows, Sub Tasks only represent Effort.
    4. Please Note: The assumption is that a full time, dedicated person would have 64 hours of capacity in a 2 weeks Sprint.

Naming Convention for Sub-tasks

A prefix of [Dev], [Services], [Framework], [Test], etc. should be placed in front of the sub-task name.

Sprint Planning output:

  1. Sprint Commitment based on Team’s velocity.
  2. Sub-task breakdown for all Stories.
  3. Sprint Goals identified and agreed to.
  4. Sprint started in JIRA.

Scrumban

On Demand Planning.

Attendees: Backlog Owner, Facilitator, Implementation Team.

When the number of work items in the “Ready” State decrease to certain thresh hold (e.g. 2 Work Items), then On-Demand Planning meeting would take place to replenish the “Ready” State.

Iteration Planning Input:

  1. Top prioritized Work Items from Backlog Owner are groomed and meets the Definition of Ready.
  2. All Team members are present (in person or over web conferencing), unless otherwise communicated to the Facilitator.
  3. Team members should know their own individual capacity for the team prior to Sprint Planning.
  4. The Facilitator displays the Team Backlog on the web conferencing/Projector.

The On-Demand Planning ceremony should follow the following guidelines:

  1. Backlog Owner should be present for the On-Demand Planning ceremony with prioritized backlog of Work Items. This requires that all Work Items are groomed with Title, Narrative, Description, Acceptance Criteria, and other supporting information as needed.
  2. Backlog Owner will discuss and re-iterate the Iteration goals they would like to accomplish during the Iteration and present the prioritized Work Items to the team, one at a time, from the top of the backlog. If the Work Item is technical, a spike, or defect, it should be readby someone from the Team. 
  3. Team may ask questions to get clarification. Details of the Work Item may be updated at this time. Further details of Work Item and Sub-Tasks can be discussed in real time when its being worked on.
  4. Every Work Item will have a SLA to when it can get completed. The SLA should be provided by the person that will be working on the item.
  5. if there is no support work raised in the current sprint then the team can take equivalent Story points from the backlog.
  6. For remote team members, it is important the Faciliatir has access to a screen sharing service, such as, WebEx to share their screen with the team. If possible, tele-presence is highly recommended. For example, if team members are in Europe and the U.S. – having a tele-presence between Europe and the U.S. helps to unite the team and make them feel more like one team. This also is helpful when doing point estimation.

On-Planning output:

  1. Work Item(s) Commitment based on WIP Limit.
  2. Iteration Goals identified, reconfirmed, and agreed to.

Kanban

Frequency

Recurring events should generally happen with a regular frequency. The specific frequency is a contextual design choice. Choose Frequencies for:

  1. Replenishing Backlog: The team meets on a agreed upon cadence to replenish the Ready state with work items from the backlog. This involves discussing, grooming, and ensure there are no blockers for that particular work Item. The number of work items moved into the Ready state depends on the team agreements, which are known as a policy in Kanban.

On-Demand

On-demand Backlog replenishment may be possible where coordination effort is low and business owners are (almost) instantly available. On-demand has the same output as “Frequency” but the meeting is triggered upon the threshold agreement (policy) with the team For example, when the work items dips below 2 in the Ready state, a replenishment must take place.

eXtreme Programming (XP)

An iteration planning meeting happens in the beginning of each iteration to produce that iteration's plan of programming tasks. Each iteration is 1 week as best practice. Work items are chosen for this iteration by the customer from the release plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected. The customer selects user stories with estimates that total up to the project velocity from the last iteration.

Each iteration essentially should look like the illustration below: