The heartbeat of Agile development is the iteration – the ability of the team to create working, tested, value delivered code in a short time box.
Iteration: The heartbeat of agility
The base construct of agile and iterative development is the iteration—the ability of the team to create working, tested, value-delivered code in a short time box—with the goal producing an increment of potentially shippable code at the end of each iteration. This is a significant challenge for the team, and mastering the process takes some time to accomplish. In this article I will try to be brief and just hit the important points I want to share.
The standard Iteration Period
Most people agree that iterations are a fixed, constant length and typically should not vary in length over the course of a release or a project. But the length of the iteration is an agile variable. From the literature, experts recommend a length of 1 to 4 weeks. But a week may be too short and a month is too long, so finally they typically arrive at is to standardize on iterations of 2 weeks in length.
There are many advantages to this approach:
- There is some overhead in planning and closing iteration; in a 2-week iteration, the overhead is well proportioned to the amount of work that can be accomplished in the period.
- Two weeks is sufficient time to get some amount of meaningful development done.
- This cycle provides more opportunities to succeed or fail early.
- The 2-week rhythm is a natural calendar cycle that is easy for all participants to remember.
- Scheduling is trivial: "If it's the second Wednesday, I need to be preparing my demo for Friday.""Demo day" occurs every other week, at exactly the same time and place, allowing key stakeholders to attend.
- Velocity can be measured and scope can be adjusted more quickly.
Planning and executing the iteration
No matter the length, all iterations have the same pattern, and that is part of the discipline and manufacturing-like routine of agile development. An iteration consists of three phases, as Figure illustrates.
- The first phase is a short planning session (less than a day) during which the iteration backlog is reviewed and prioritized, estimates are established, and the team commits to the work in the iteration.
- The second is the development phase, when the backlog items are implemented in code and tests.
- The final phase involves delivery of the new system increment built during the iteration and assessment of the iteration.
Iteration Planning
At the beginning of each iteration, the team holds an iteration planning session during which it reviews the prioritized items in the backlog, selects and reviews the stories for the current iteration, and defines and estimates the tasks necessary to deliver the increment of work. There is a high degree of granularity involved because tasks are typically estimated in "ideal developer days" or even hours. In keeping with the agile practice of just-in-time design, it is during this session that the details of the requirements are discussed and negotiated.
The primary concern of iteration planning is to define and accept a reasonable scope for the iteration. Iteration planning begins with revising and refining the list of prioritized work in the backlog. Product owners and the development team may add or reduce features, defects, and other infrastructure work on the basis of the current business situation. Business priority, risk, and rough estimates are assigned to new items or may be revised for existing items. The product owners then re-rank the work items and select a scope of work to propose for the iteration.
The development team is given an opportunity to discuss the proposed work with product owners until each item is well enough understood for the development team to prepare a list of engineering tasks and provide detailed estimates. The development team then estimates the engineering tasks for each proposed backlog item. The development team then presents its estimates to the product owners.
By adding up the development team's estimates, the team can calculate the apparent scope of the iteration and have an indication of whether the scope can be achieved. However, the final scope of the iteration is the result of a negotiation between product owners and the development team. During this negotiation, product owners may adjust certain backlog items in ways that make them less costly to develop, trade out entire backlog items for others, or ask for adjustments to certain estimates provided by development.
The team should keep the following guidelines in mind during the iteration planning meeting:
• Have the iteration planning meeting on the first day of the iteration, first thing in the morning. The meeting should last no more than 4 hours.
• Create task estimates for each story on the basis of ideal effort hours, or points.
• When estimating, if a story breaks out into seven or more tasks, consider splitting the story.
• Be sure that there is at least one story with a demonstrable function included in the iteration.
• Remember that the product manager owns the story priorities, and the development team owns the tasks and the estimates for those stories.
• When first implementing agile practices, consider setting a "code freeze" a few days prior to the end of the iteration, because the team is likely still practicing waterfall within the iteration.
• Remember that the team's velocity (available resources factored by existing velocity) changes from iteration to iteration.
• Once the iteration is underway, no change requests by the product manager are allowed. Any new or changed stories should go into the backlog.
Iteration Cycle
Iteration cycle is repeated until all backlog items are completed. The following figure illustrates the iteration cycle:
Take Responsibility
Having committed to the iteration plan, the team is faced with the question of how to allocate that work to the members of the development team. The two basic approaches to allocating work are that the Agile/Scrum. Master can assign work to developers or the developers can choose the work they will do.
The process of developers taking responsibility for work must be supported by a visible indicator showing who is responsible for what work and by daily status meetings during which status and issues can be discussed.
Develop
Once a developer takes responsibility for a backlog item, he or she then:
• Elaborates requirements (if not already elaborated).
• Designs.
• Writes the test (first in some practices) and writes the code.
• Executes the test suite on the build.
• Integrates program code and tests into a build of the system.
Deliver Story
The developer delivers the new functionality or defect fix by checking the code into the source control system and including it in a build of the system. The unit test suite and other appropriate tests are run before the code is checked in to ensure that the changes do not break the build.
Declare Story Completion
Once the developer has integrated his or her work into a build of the system, the backlog item is declared complete, signaling other members of the development organization that the backlog item is ready. For example, the testing group now knows it can include the new functionality or defect fix in its testing efforts and can start automated tests of various kinds (functional, acceptance, performance, etc.).
Accepting the Iteration
The final activity in an iteration is to reflect on and assess the results. The goal of assessment is to mine the lessons learned during the iteration and then adapt the development process accordingly. The assessment allows the team to continually improve the throughput of the development process and the quality of the resulting system.
The other major activity that occurs during assessment is a "closing" process whereby unfinished items are put back into the release backlog as work to be done. The iteration is concluded, and the closed iteration backlog becomes a record of the work completed during the iteration.
Tracking Iteration
Since there are relatively few stories in an iteration, tracking the status of each is a fairly simple matter, and it provides an objective look at progress. Status can be tracked by hanging visual indicators of state information (defined, complete, accepted) on the wall, moving cards from one area of a wall to another, or for larger and distributed teams, using automated tools.
Since iterations are fixed in duration, another primary way the team and its managers can gauge progress in the aggregate is to continuously monitor current status and also estimate how much work remains. Computing the estimated remaining work in the iteration at a given point in time requires two pieces of information: the total of the estimates for all backlog items that are not yet started and the estimated remaining effort for any in-progress backlog item. The sum of those two amounts represents the estimated remaining work to be completed during the iteration. Plotting this value each day of the iteration produces what is called a burndown chart, as the example in Figure illustrates.
References
- Mastering the Iteration: An Agile White Paper, Rally Software Development Corporation.
- ScalingSoftware Agility: Best Practices for Large Enterprises, Addison-Wesley, 2007
No comments:
Post a Comment