What you need to know before going into an Iteration Planning Meeting?

Iteration Planning Meeting

If you are preparing for the PMI-ACP exam, you need an understanding of what happens in an Iteration planning meeting. This post gives you some insights.

 

Iteration / Sprint:

First, let us begin with our understanding of an Iteration.

An Iteration is a fixed block of time where the team works on a committed number of User Stories that provide value to the end user.

The word ‘value’ is very important. If the team works on a set of User Stories, but if all the User Stories put together with an Iteration does not generate any value to the end user, it is better to abandon such a Sprint.

So how do we plan our Iterations so that they provide value to the end-user? The answer lies in Iteration Planning.

 

Iteration Planning Meeting:

Iteration planning is done at the beginning of every Iteration. The main goal of an Iteration planning meeting is to decide on the number of User Stories that will be completed by the team in the next Iteration. Of course, they should provide value to the end user after the end of an Iteration.

So before going into any Iteration, the team meets with the Product Owner and Scrum Master to plan for the Iteration. This is the Iteration Planning Meeting & is one of the most important events in Scrum.

Just before the Iteration Planning, the Product Owner grooms the Product backlog, preparing a list of prioritized items that are most valuable to the business. To be considered for an Iteration, the Product Backlog items:

  • Needs to be sufficiently sized with story points.
  • Needs to be sufficiently broken down, so that it can be completed within the duration of the Iteration
  • Needs to have enough acceptance criteria which can validate the implementation of the development effort within a Sprint.

The Product Owner, the Scrum Master, and the development team participate in the Iteration planning process. During the Iteration planning meeting, the Product Owner presents the list of prioritized items to the team. The team, based on the past data of its velocity (number of story points completed within an Iteration), selects the top ‘N’ items that it feels it can accommodate within the next Iteration. They can look at the velocity numbers of either the last Iteration or they can take an average of the last few Iterations.

For example, if the average velocity of the team for the last 5 Iterations is 12 story points, the team would just pick the first 3 items from the below Product Backlog.

 

                                     

 

A prioritized list of items in a Product Backlog:

 

User Story ID

Priority

User Story

Story Points

3465

1

Integrate the Payment Gateway to the E-commerce site

5

4321

2

The user should be able to checkout using American Express cards

5

7645

3

Allow the option to checkout using cash on delivery

1

8723

4

 allow the user to apply coupon codes during the checkout process

4

Once the team decides on the first 3 items, the Product Owner discusses these items, elaborating the acceptance criteria and how the functionality should behave. The team shall ask clarifying questions, raising issues & voicing any concerns. During this natural process of interaction, the team will be able to break down the User Stories into tasks. The idea is not to thoroughly breakdown a user story into different tasks, but rather the team should go through that enlightening discussion of the user story with the Product Owner.

Once the team breaks down the User Stories into tasks, it can assign the number of hours it could take to complete those tasks and it can also assign the team member who will be responsible for completing the task. Suppose, for example, after a detailed discussion of the User Stories & tasks, the team breaks down the above 3 User Stories with the following estimated duration:

 

Potential Sprint Backlog with detailed tasks:

 

User Story

Tasks

Assigned To

Estimated Hours

 
Integrate the Payment Gateway to the E-commerce site

Creating a PayPal account

Ravi

16 hours

 
 

Handling payment notification from Webhooks

Ram

10 hours

 
 

Handle recurring payment

Ravi

9 hours

 

The user should be able to checkout using American Express cards

Integration with American Express APIs

Ram

10 hours

 

Designing the database layer with encryption

Ravi

5 hours

 

Allow the option to checkout with Wallet

Integrate with Paytm

Ravi

7 hours

 

Integrate with FreeCharge

Ram

7 hours

 

                   

                       

 

A look at capacity:

Let’s suppose the team works in Iterations of one-week length and there are 2 resources within the team namely Ravi and Ram. And for the next Iteration, since we have 5 working days and 2 people working, we have a total of 10 working days. And out of the 10 working days, Ravi is on planned leave on Thursday, so now, we have a total of 9 working days.

Ideal hours per day is 6 hours (accounting for lunch breaks, tea breaks, meetings, etc.)

Total hours available in the Iteration = 9 days * 6 hours/day = 54 hrs

After looking at the available capacity data, we see that only the first 2 User Stories can be taken up within the Iteration, and the team commits to completing only those 2 User Stories. In Agile, the team decides what it can complete. The Product Owner or the Scrum Master cannot force the team to commit to more work.

 

Final Sprint Backlog with detailed tasks:

 

User Story

Tasks

Assigned To

Estimated Hours

 
Integrate the Payment Gateway to the E-commerce site

Creating a PayPal account

Ravi

16 hours

 
 

Handling payment notification from Webhooks

Ram

10 hours

 
 

Handle recurring payment

Ravi

9 hours

 

The user should be able to checkout using American Express cards

Integration with American Express APIs

Ram

10 hours

 

Designing the database layer with encryption

Ravi

5 hours

 

 

 

Outcomes of Iteration Planning Meeting:

So the above 2 User Stories constitute to what is called as the Sprint Backlog. The Sprint Backlog is one of the 2 outcomes of the Sprint planning meeting. The Other outcome is the Sprint goal.

 For example, for this 1 week Sprint, Sprint goal can be

Implement basic features that would allow a merchant to collect payment from the customer.

The Sprint goal is essential because various stakeholders of the project may not have the time to go through the list of User Stories that the team is currently working on, rather, they would prefer a one-line statement such as the Sprint goal.

So, the Sprint Backlog & the Sprint Goal act as the guiding factor for the team to complete its work within the Iteration that would add value to the end user.

Preparing for PMI-ACP? Check out the PMI-ACP path available in Pluralsight with a free trial

As always, please leave your comments. I’d really appreciate them.


Want to be notified as soon as I post? Subscribe to RSS feed / leave your email address in the subscribe section. Share the article to your social networks with the below links so it can benefit others.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *