The Scrum framework is based on a series of cycles (The Scrum Cycle) that teams use to iteratively uncover, produce, enhance, and release results that reflect customer wants and needs. Each of these cycles requires close collaboration and engagement of Scrum practitioners and committed stakeholders to guarantee that products (or product increments) accurately reflect requirements and satisfy requests. Each stage of the cycle should be timeboxed to a maximum duration to ensure that value is delivered quickly and efficiently to consumers and end users.
The Scrum Cycle: An Overview
Often, customers can’t identify all of their needs, wants, and requirements at the start of a project so Scrum uses a series of rapid, iterative cycles each with its own plan, design, build, and test segments to uncover these requirements and continually produce outcomes that meet immediate needs. In each of these cycles, customers and stakeholders collaborate with an extended scrum team to uncover and refine requirements so outcomes will specifically address and satisfy their demands. These cycles result in incremental releases that, when combined, will provide a finished product that meets or exceeds expectations.
A Scrum development cycle has six “stages”:
- Creating a product vision and product backlog
- Planning a sprint
- Executing the work in the sprint
- Reviewing the product created in the sprint
- Reviewing the sprint’s processes
- Beginning the next sprint or releasing the product to the customer
Stage 1: Creating a Product Vision and Product Backlog
The Scrum development cycle begins with the scrum team and customers establishing a clear vision of what the product should be and expressing that vision in a collection of user stories. The user 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.
In some instances, stories may be 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
Product owners then compile the accepted user 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 (with some input from the scrum master) 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 sprints 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 a Sprint
The product owner then convenes a meeting with the scrum team to plan the sprints 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 sprint as a newspaper headline, to quickly convey the vision for the sprint and create a simple 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 sprint, and break the items into the tasks needed to satisfy the requirements. They compile the tasks into a sprint backlog 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 that 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 an index card
Front of index card: As an online student, I would like to see my last 10 test scores so I can review my progress.
Back of index card:
- Design Layout
- Design database queries
- Enable filtering by dates or completion status
The team selects the items from the product backlog that have the highest priority and that can be completed within the current sprint. Any additional items of lower priority that can also be accomplished in the remaining sprint 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 sprints.
Scrum teams must be very careful not to include too many tasks in a given sprint. Sprints 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 sprint is its velocity. Scrum teams need to plan their sprints at a velocity that could be maintained indefinitely. Doing so will ensure that the team does not exhaust itself in each sprint.