Agile Iteration Planning

Agile iteration:

Agile iteration is a consistent time-box in which a delivery team plans, delivers and receives feedback on a product increment.

Iterative Development adds agility to the development process. Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant through out the project. This is the heart beat of your project.

Take your iteration deadlines seriously! Track your progress during an iteration. If it looks like you will not finish all of your tasks then call another iteration planning meeting, re-estimate, and remove some of the tasks.

Key characteristics of an iteration:

• Have one goal
• Focus on completing the tasks derived from user stories
• Accept the activities based on the capacity of the team

Iteration Plan:

At the start of each iteration - or sprint to use the Scrum term - the team set out what they will do in the next iteration. Since iterations typically last weeks - with two weeks being most common - these plans only peek a little into the future. They are however the most detailed plans, setting out exactly

what the team will do.

The scheduling of work into an iteration plan is a discussion between the team members who will undertake the work and those who are charged with managing the requirements side of the project. Whoever this is, be they Product Owner, Customer, Product Manager, Business Analyst or Project

Manager, proposes some work. Then using a velocity measure or a goal commitment protocol the team agree how much the team can accomplish.

Once agreed the iteration plan is done and the team move to execution. While the Product Owner nominates work to the plan it is agreed with the team through negotiation. Having the whole team involved in the planning removes the need to communicate the plan to the team, explain details and

enthuse the team about someone else's plan.

Once agreed the iteration plan is owned by the team and it is their collective responsibility to carry it out. Since the plan only looks at the next few weeks it is unlikely to change much. Indeed, when it does change drastically it is usually a sign of problems. When this happens regularly it is a sign that action needs to be taken.

Iteration planning steps/life cycle:

• Select Iteration goal
• Determine delivery team capacity
• Select the highest priority backlog item
• Estimate tasks
• Repeat until no more can be committed

Product Owner Responsibilities

• Review the release plan to make sure the vision and goals are still appropriate.
• Review the items in the backlog and reprioritize if necessary
• Understand how the reprioritization may affect other teams who are dependent on a deliverable committed to during release
• planning. Coordinate with other product managers as needed to resolve dependency issues.
• Understand the customer needs and the business value that each story is to deliver.
• Be prepared to further elaborate on the details of each story.

Development Team Responsibilities

• Review the top priority items in the backlog and prepare any questions
• Consider technical issues, constraints, and dependencies, and be prepared to share these concerns.
• Think about the work involved in delivering the functionality in the stories, in order to be prepared to make estimates in the meeting.
• Understand what your iteration velocity should be for the upcoming iteration, based on team discussions at the last review.

Release Plan:

The release plan is then used to create iteration plans for each individual iteration.

It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.

The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. No dependencies, no extra work, but do include tests. The customer then decides what story is the most important or has the highest priority to be completed.

User stories are printed or written on cards. Together developers and customers move the cards around on a large table to create a set of stories to be implemented as the first (or next) release. A useable, testable system that makes good business sense delivered early is desired.

The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be.

Tips for successful iteration planning:

• Prior to planning, review the prioritized list of stories, estimate at the gross level and select stories for the iteration.
• Time-box your iteration planning session.
• Determine delivery team capacity.
• Agree upon statement of what the iteration is intended to accomplish.
• Break stories into tasks, estimate efforts at the hours level for tasks and sign-up owners.
• Get commitment from team.
• Track the plan in a visible place or a tool.
• Review and update the definition of the DONE.

Iteration Execution

Having committed to the iteration plan, the team starts development. Each developer (or pair of developers in organizations doing pair programming) will follow the same basic process repeatedly

throughout the iteration until there is no more work in the backlog:

1. Take responsibility for an assigned backlog item (e.g., story, use case, defect fix, other).

2. Develop (design, code, integrate, and test) the backlog item.

3. Deliver the backlog item by integrating it into a system build.

4. Declare the backlog item as developed, signaling that it is ready for acceptance testing.

This cycle repeats within an iteration as each developer ultimately takes responsibility for all the backlog items in his or her queue. In most organizations, developers also support the management of the process by estimating actual and remaining effort for the backlog items that they are responsible for.