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 throughout 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.
