The Agile Cycle

The Agile development cycle contains six “stages”:

• Creating a product vision and product backlog
• Planning an iteration
• Executing the work in an iteration
• Reviewing the product created in an iteration
• Reviewing the iteration’s processes
• Beginning the next iteration or releasing the product to the customer

The Stages of the Agile Cycle

Stage 1: Creating a Product Vision and Product Backlog

The Agile development cycle begins with the Agile team and customers establishing a clear vision of what the product should be. This vision is expressed in a collection of customer requirements called features or stories. Stories are not technical specifications of the product’s size, volume, or performance—instead, they are high-level descriptions of what the user wants the product to do. As such, stories are specifically worded to reflect the customer’s intended use and to keep the product focused on meeting customer needs rather than meeting technical specifications.

Stories are often captured on 3″x5″ index cards to limit the amount of space available to document requirements. Limiting the available space ensures that the story remains simple and concise and that the requirement description is focused.

Example of a story on an index card

Agile product owners compile stories into a product backlog. The product owner, as the “keeper” of the product backlog, continually updates and prioritizes this list, acting on the customer’s behalf to ensure that the highest priority items are delivered first. The product owner refines the highest priority requirements (and, therefore, those that are likely to be implemented first) to a greater degree and leaves requirements of lower priority to be refined later. The product backlog may also include requirements that are necessary for the creation and improvement of the product, but that may not be visible to the product’s customer.

The product owner then sets the boundaries for the project—what will be delivered, who will be involved, and how the project team will work together. These boundaries are not developed in detail; they include only enough documentation and advanced planning so that the output produces value for the customer. This plan determines how many iterations can be completed before the product will be released to the customer and focuses on increments that meet customer requirements and deliver business value. It also creates a timebox that constrains the time allotted for the project’s completion and helps guard against an indiscriminate expansion of scope.

Stage 2: Planning an Iteration

The product owner then convenes a meeting with the development team to plan the iterations for the project. The product owner discusses the vision for the product, the customer requirements, and the priorities for satisfying those requirements. He or she answers any questions the team may have and provides any necessary clarification or elaboration. Often, the product owner is asked to present the goal of the iteration as a newspaper headline, to quickly convey the vision for the iteration and create a simply shared understanding and focus for team members.

Team members then estimate the amount of work that they believe each story will require. These estimates are often set, not as absolute time amounts (like hours or minutes), but rather as story points that compare requirements in relation to each other. Because product developers are individuals that work at different rates based on their experience and effort, estimating tasks in hours or minutes will vary depending on which individual is performing the work. Using story points to estimate time is meant to be an independent measure, regardless of who is performing the task. A story estimated at 20 story points should take twice as much work as a story worth 10 story points, which would take twice as much work as a story estimated at five story points. This allows the team to estimate the amount of work it will need to do based on how “big” the task will be, not on how fast it is thought an individual can do the work.

Team members then select those items from the product backlog that they can complete within the time frame for the iteration, and break the items into the tasks needed to satisfy the requirements. They compile the tasks into a task list that they will use as an inventory of the work in the iteration. The tasks are written in the technical language that the team will use to satisfy the requirements. Tasks are often written on the back of the index cards of the customer stories the tasks will address; this allows matching of the tasks to the requirements if needed.

Example of a task on the back of index card.

The team selects the items from the product backlog that have the highest priority and that can be completed within the current iteration. Any additional items of lower priority that can also be accomplished in the remaining iteration time are included, but any items that the team would be unable to complete are returned to the product backlog to be reprioritized for subsequent iterations.

Agile teams must be very careful not to include too many tasks in a given iteration. Iterations should be balanced so that the team continues to satisfy requirements but does not take on so much work that members need to put in long hours to accomplish their goals. The amount of work that a team can accomplish in a given iteration is its velocity. Agile teams need to plan their iterations at a velocity that could be maintained indefinitely. Doing so will ensure that the team does not exhaust itself in each iteration.

Stage 3: Executing the Work in an Iteration

After the iteration is planned, the project team must ensure that work will be completed. Individuals on Agile teams take responsibility for finishing their work on each iteration. Daily stand-ups* help to keep team members focused; these 15-minute meetings (which should be attended by all team members) allow each team member to explain:

1. What he or she accomplished yesterday
2. What he or she is working on today
3. What issues are impeding work progress

These meetings not only make completed work visible to team members but also make sure relevant information is shared on a regular basis. They create peer pressure among team members; each team member is expected to show progress each day and is held accountable by other team members (not by the product owner or other stakeholders) for getting work done.

Teams can demonstrate their progress to stakeholders on story boards. Two of the most commonly used story boards are burndown charts and burn-up charts. Burndown charts* show how many tasks the team has completed each day and how many tasks remain until the iteration is done. Burndown charts are often drawn as line charts, with time listed on the x-axis and the number of tasks on the y-axis. As the project progresses, the slope of the line decreases until it intersects with the x-axis at the completion of the iteration. Some teams track both the planned burndown and the actual burndown to show how close they will be to an expected iteration completion date.

Burndown chart

Burn-up charts also show team progress, but show the accumulation of completed stories rather than the number of stories yet to be completed. The slope of the line in a burn-up chart increases (instead of decreases) to show team progress.

Burn-up chart

Stage 4: Reviewing the Product Created in an Iteration

At the completion of each iteration, the team meets with the product owner, customers, and other stakeholders to demonstrate the products they created in the iteration. These iteration reviews are short meetings (roughly two-to-four hours in length) that present team results as simply as possible, with little or no fanfare or complex presentations. The team presents complete working products—not prototypes or documentation describing how the product would work—to customers and stakeholders for review and analysis.

Stakeholders and customers ask questions about the product and provide feedback, which the team then translates into new customer stories and adds to the product backlog for inclusion in subsequent iterations. The lessons learned from iteration reviews allow products to evolve as users and customers interact with working products and voice new expectations and needs.

Stage 5: Reviewing the Iteration’s Processes

When iteration review meetings are complete, teams then turn their attention to an analysis of project dynamics: how well team members worked together and how well their processes worked. These iteration retrospectives allow teams to revise their development processes before continuing into subsequent iterations, by analyzing:

• How well the product worked, from both the customer’s perspective and the technical point of view
• How well the processes used to create the product worked
• How well the team interacted within the iteration
• How well the project met the organization’s intended goal

These retrospective meetings are usually one-to-three hours in length and provide the feedback that the team needs to adapt its work structure and its relationships before new iterations or projects begin.

Change Control

The Agile methodology is designed to accommodate change, but that doesn’t mean that changes are introduced without regard to structure. Iterations are planned to deliver solutions to specific customer needs; adding additional requests to an ongoing iteration would only complicate the iteration planning and delay the work already in progress. To prevent such a problem, Agile practitioners incorporate change and make adjustments between iterations, not within an iteration. Any requests for change should be presented to the product owner, who will then add them to the product backlog for possible incorporation into future iterations of work.

Stage 6: Beginning the Next Iteration or Releasing the Product to the Customer

At the end of each development cycle, the project team either releases the product to the customer or begins the next iteration in the project.

Release Planning

The development cycle previously described is part of a larger organizational cycle—the release cycle. The release cycle specifies when an organization will release products to its customers. The release plan documents the product release dates; these dates may be set by either:

• deciding what date an organization wants to release a product (based on market research or customer requests), then determining how many features can be completed before that date, or
• deciding how many features to include in a new product, then determining how long it will take to complete those features.

Release plans become more detailed as Agile teams mature. As teams complete more iterations, their velocity becomes better understood and release dates can be estimated with greater accuracy. Once a product is released, the organization reviews its product roadmap and begins to develop new products in a new round of release planning.

Release Plan

Review Checkpoint

To test your understanding of the content presented in this assignment, please choose the correct answer

1. How long are daily stand-ups?Choose only one answer below.

a. 10 minutes for each participant

b. 15 minutes long

Correct. Daily stand-ups are 15-minute long meetings in which team members explain what they accomplished yesterday, what they are working on today, and what obstacles are preventing their progress.

c. One-to-three hours in length

d. However long it takes to discuss project impediments

2. Which of the following is not true about iteration reviews and retrospectives?Choose only one answer below.

a. Teams conduct iteration reviews before they perform iteration retrospectives.

b. Stakeholders provide feedback to team members on a product’s performance in iteration reviews.

c. Teams review the processes they used in iteration retrospectives.

d. The lessons learned in iteration retrospectives allow products to evolve as users and customers interact with working products.

Correct. The lessons learned in iteration reviews allow products to evolve. The lessons learned in retrospectives allow processes to evolve.