From Sprint to Sprint
Scrum processes develop the project from the planning phases, through the sprint, to the next sprint, until the project is completed. In the last article in this series, you received an overview of the Scrum methodology and learned about Scrum time boxes. Processes take the time boxes, the Scrum roles, and work with the artifacts to complete a scrum project and produce a quality product.
Before you can understand the Scrum process, it is important to first understand Scrum artifacts. Scrum artifacts are lists and schedules created in order to facilitate the completion of work during a Sprint.
Product Backlog – The product backlog is a prioritized to-do list. Anytime a task comes up during the duration of the project, the task is added to the product backlog and the list is re-prioritized. The only items on the product backlog that are detailed are the items that are of the highest priorities. This is done in order to ensure that extra and unnecessary work is not undertaken.
Release Burndown – The release burndown maps out in graphic form the relationship of the items on the product backlog to the time left in the Scrum project. During release planning, the initial release burndown chart is created; thereafter, it is updated as the product backlog changes.
Sprint Backlog – During the Sprint development session, the items that will appear on the sprint backlog for completion are determined. The sprint backlog does not change during the Sprint. Instead, team members complete the items on the backlog during the sprint duration – if additional items come up, then those items are placed on the product backlog for a future sprint. If the sprint becomes impossible to complete unless one of these new issues is completed, then the sprint is canceled and the team goes back to the sprint development meeting stage, generating a new sprint backlog in the process.
Sprint Burndown – The sprint burndown, like the release burndown, is a scheduled chart, but this chart demonstrates the relationship between items on the sprint backlog and the time left in the sprint. The sprint burndown demonstrates all the work left in the sprint.
Applying Scrum Processes to a Project
Because Scrum involves rigid rules for its implementation, the process for applying Scrum to a project is fairly straightforward. Imagine you are creating a video game program for your employer. You will have a product release planning session to discuss the requirements for the game. Once the requirements have been determined, then you will begin to assemble the product backlog. The first sprint development meeting will be conducted, during which the initial sprint backlog will be derived from the product backlog. A sprint burndown chart is created. The sprint begins and your coworkers and team members begin completing the work for the sprint. Thirty days go by, many issues and tasks have been identified, and you have a sprint review meeting to discuss what has been completed for the video game and what needs to be completed in the next sprint. This cycle will repeat until the product reaches completion and achieves its first release.
This post is part of the series: Understanding Scrum – Part I
- Understanding Scrum – Methodology
- Understanding Scrum – Processes
- Understanding Scrum – Environment
- Understanding Scrum: Basic Q&A
- Understanding Scrum – Project Planning Templates and Samples