Iteration Planning

The purpose of the iteration planning meeting is for the team to commit to the completion of a set of the highest-ranked product backlog items. This commitment defines the iteration backlog and is based on the team's velocity or capacity and the length of the iteration time-box.

Who is Involved?

Iteration planning is a collaborative effort involving these roles:

• Scrum Master: Facilitates the meeting

• Product Owner: Represents the detail of the product backlog items and their acceptance criteria

• Delivery team: Define the tasks and effort necessary to fulfill the commitment

Before the Planning Meeting

Before getting started, ensure:

When you have a good foundation in business analysis, and possess a proven skill set (hopefully cultivated along the way of your experiences), then you are more than capable of transitioning, and utilizing those skills to, and in, any type of methodology or environment. Yes, you may need some additional awareness education, but that falls in line with your personal commitment to professional development and is no more of a problem than packing up your BA tool bag on one job site and unpacking it somewhere else.

• The items in the product backlog have been sized by the team and assigned a relative story point value

• The product backlog is stack ranked to reflect the priorities of the Product Owner

• There is a general understanding of the acceptance criteria for these ranked backlog items

Equal opportunity backlog

The product backlog addresses new functionality and fixes to existing functionality. The order in which a product backlog item is scheduled is completely independent of its ancestry.  

For the purpose of iteration planning, the important characteristics for a product backlog item are:

• It is small enough to be completed in the iteration

• We can verify it has been implemented correctly

Right-size backlog items

Product backlog items too large to be completed in an iteration need to be split into smaller pieces. The best way to split product backlog items is by value, not by process.  

If we can split a product backlog item so that its children deliver value, then our iterations incrementally deliver value. If we split by process, then we impact time-to-market because value is not delivered until all the children are complete.  

Compound stories can be easily split through disaggregation. Complex stories present a different challenge. Use the Bill Wake INVEST or SMART mnemonic (Specific, Measurable, Achievable, Relevant, Time-boxed) as a technique for story splitting.  

These "splits" may help give you ideas when you're looking for a way to move forward in small steps. While it's important to be able to split stories, don't forget that you have to reassemble them to get the full functionality.

Planning process

Planning the contents of an iteration has two stages: determining how many user stories can be taken into the iteration, then breaking those stories down into tasks and assigning owners.  

Sizing refers to the relative scope of a user story, and is usually done in relative points. The team periodically estimates the size of a user story, when it is first created, during backlog grooming sessions, and before the planning meeting. By the time planning begins, the team should know what stories near the top of the backlog can be taken into the upcoming iteration.  

Estimation refers to the breakdown of a user story into tasks. Once small steps necessary to deliver a user story are identified, each task is given an hourly estimate. This figure keeps the team updated on how close a task is to being completed. The team also knows how many task hours each team member has available in the iteration (known as capacity), to prevent individuals from being overburdened.

User story points should not translate into or be compared with total task hours.

User story size

Mature teams use past velocity to determine what product backlog items to commit to during the iteration. Velocity is the average number of user story points a team can complete in an iteration. For example, a new team completed 12, 14, and 8 points in their last three iterations. Review meetings revealed that the team was only able to complete 8 story points in the most recent iteration, due to a technical issue that has since been solved. Based on these factors, the team would estimate they have a velocity of 12 story points, to use in the next iteration.

When creating an iteration in an agile management system, use the Planned Velocity eld to record how many user story points (or other value) the team thinks it can complete.  

New teams may not know their velocity, or it may not be stable enough to use as a basis for iteration planning. An approach for new teams is to make commitments with a best guess based on past project work. If the team quickly completes all of the scheduled work, more can be pulled in. If the velocity estimate is too low, the team should commit to less work in the following iteration.

Task capacity

The capacity for the team is derived from three simple measures for each team member:

• Number of ideal hours in the work day

• Days in the iteration that the person will be available

• Percentage of time the person will dedicate to this team

For example, let's look at a team of ve individuals, all committed to the team full-time. Each has about six ideal hours per day to work on tasks, and no one is taking vacation.

For a week-long iteration: 5 team members X 6 ideal hours X 5 working days = 150 hours of task capacity.

Planning steps

1. The Product Owner describes the highest ranked product backlog item.

2. The team determines the tasks necessary to complete each product backlog item.

3. Team members volunteer to own the tasks.

4. Task owners estimate the ideal hours they need to finish each task.

5. Planning steps repeat while the team can commit to delivery without exceeding optimum velocity.

If any individual exceeds their capacity during iteration planning, then the team collaborates to distribute the load.

Agenda

1. Opening  

Welcome meeting participants, review purpose, agenda, and organizing tools.  

2. Product vision and roadmap  

Remind the team of the larger picture.  

3. Development status, state of our architecture, results of previous iterations  

Discuss any new information that may impact the plan.  

4. Iteration name and theme  

Make a collaborative decision on name and theme.  

5. Velocity in previous iterations  

Present the velocity to be used for this iteration.  

6. Iteration timebox (dates, working days)  

Determine the timebox and total working days. Subtract days for holidays or other whole team-impacting events.  

7. Team capacity (availability)  

Each team member calculates their capacity based on personal availability, allocation to this and other projects, productive time for tasks in this iteration each day.  

8. Issues and concerns  

Check in on any currently known issues and concerns and record as appropriate.  

9. Review and update Definition of Done  

Review the Definition of Done and make any appropriate updates based on technology, skill, or team makeup changes since the last iteration.  

10. Stories or items from the product backlog to consider  

Present proposed product backlog items to be considered for the iteration backlog.

11. Tasking out  

Delivery team determines tasks, signs up for work, and estimates tasks they own.

Product Owner answers clarifying questions and elaborates acceptance criteria as appropriate; Scrum Master facilitates collaboration. a. Tasks, b. Estimates, c. Owners  

12. New issues and concerns  

Check in on any new issues and concerns based on tasking out and record as appropriate.   13. Dependencies and assumptions  

Check in on any dependencies or assumptions determined during planning and record as appropriate.  

14. Commit!  

Scrum Master calls for a fist of five on the plan. Agile team and Product Owner signal if this is the best plan they can make given what they know right now and commit to moving to the next level of planning—daily.  

15. Communication and logistics plan  

Review and update communication and logistics plan for this iteration.  

16. Parking lot  

Process parking lot—all items should either be determined resolved or turned into action items.  

17. Action items/plan  

Process action plan—distribute action items to owners.  

18. Retrospect the meeting  

Because we want these meetings to be useful for everyone, we solicit feedback on the meeting itself.  

19. Close  

Celebrate a successful planning meeting!

#efforlessbusinessanalysis #businessanalysis #iamaba #agile #iterationplan