Stage 3: Executing the Work in a Sprint
After the sprint is planned, the project team must ensure that work will be completed. Individuals on scrum teams take responsibility for finishing their work on each iteration. Daily scrums help to keep team members focused; these 15-minute meetings (which should be attended by all team members) allow each team member to explain:
- What he or she accomplished yesterday
- What he or she is working on today
- 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 sprint 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 sprint. Some teams track both the planned burndown and the actual burndown to show how close they will be to an expected sprint 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 a Sprint
At the completion of each sprint, the team meets with the product owner, customers, and other stakeholders to demonstrate the products they created in the sprint. These sprint 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 sprints. The lessons learned from sprint reviews allow products to evolve as users and customers interact with working products and voice new expectations and needs.
Stage 5: Reviewing the Sprint’s Processes
When sprint 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 sprint retrospectives allow teams to revise their development processes before continuing into subsequent sprints, 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 sprint
- 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 sprints or projects begin.
Change Control
The Scrum framework is designed to accommodate change, but that doesn’t mean that changes are introduced without regard to structure. Sprints are planned to deliver solutions to specific customer needs; adding additional requests to an ongoing sprint would only complicate the sprint planning and delay the work already in progress. To prevent such a problem, Scrum practitioners incorporate change and make adjustments between sprints, not within a sprint. 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 sprints of work.
Stage 6: Beginning the Next Sprint 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 sprint 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 scrum teams mature. As teams complete more sprints, 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
Recommended for you What is Scrum?
