Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Scrum process flow

Log in to subscribe to topics and get notified when content changes.

Scrum process flow

Outlines the process flow for the Agile Development application from plugin activation to the completion of a sprint.

The flow described in this document represents a common practice for creating and managing scrum records with the functionality provided in the base Agile Development and is not intended to represent the only possible process. Use the links provided to examine detailed instructions for each task. Each procedural page contains prerequisite information and instructions for accessing the next task in the sequence.

Create a product

In scrum, a product represents functionality that a product owner has identified as important to customers.

A product contains the themes, epics, and stories that describe these enhancements from the perspective of a user. Products can have a narrow focus with few user stories or a wider context with many user stories, each containing several tasks. You create products first and then add themes, epics, or stories to create the product backlog.

For more information, see Products.

Create user stories

A user story is a brief statement of a product requirement or a customer business case created by a product owner.

Typically, stories are expressed in plain language to help the developer understand what the software should accomplish. Stories contain specific tasks for work that can be resolved in one sprint. Stories that take longer than a sprint to complete should be broken into one or more stories and grouped into an epic. Stories and epics can be associated with themes, which are the highest level goal or objective. Agile Development enables administrators to add stories at different points throughout the scrum process as necessary to react to changes in feature scope or resource availability. You cannot create a story without associating it to a product. A story cannot be associated with more than one product, release, or sprint.

For more information, see Scrum user stories.

Create a release

A release has a start and end date during which several development iterations are completed.

When a release record is created, at least one scrum team and its members should also be created. A release team can be reused for each sprint within the release. For each team member, a default number of story points can be defined and applied to the sprints. At the sprint level, the sum of the team member story points determine the team’s capacity. Sprints inherit the default team and team members of the parent release. At the sprint level, the release planner can override the structure and number of points assigned to a team member if necessary to support the availability of the team members on a sprint-by-sprint basis.

For instructions on creating a release backlog and development teams, see Releases in Scrum.

Create a sprint

A sprint is the basic unit of time in the development process.

A sprint can be of any length, but typically takes between one and four weeks to finish. The scrum master creates one or more sprints from within a release. All sprints within a release must fit within the release start and end dates. The scrum team is expected to complete all stories to which it is committed within a sprint and to meet the acceptance criteria as defined in the story records. The scrum master expects that the stories are fully tested and potentially releasable. Usually, the committed stories for a specific sprint should not change during the sprint. However, the Agile Development application makes changes possible if necessary. Stories should be added or removed from a sprint only after a discussion with the team, scrum master, and product owner.

For instructions, see Sprints in Scrum.

Plan the sprint

Before a sprint starts, the team and scrum master decide on what stories they can commit to completing within a sprint. Then the scrum master manages the sprint team efforts, provides progress reports, and removes any impediments that the team encounters.

The scrum master must make sure that the effort (story points) required to complete the stories matches the capacity of the release team. If the effort exceeds the capacity, the scrum master can add team members, remove stories, or add sprints as needed. A velocity chart is available to help in the estimation process. The velocity chart shows historical record for a team of the number of completed points, by sprint. This view gives the scrum master an idea of the general capacity of the team over time and produces more accurate sprint planning. Velocity charts are the most meaningful when sprint duration is constant and the available points for team members do not change between sprints. Use the velocity chart as guidance and not as a factual representation of what the team can produce in the next sprint.

Team members update task and story records and conduct daily stand-up meetings (scrum meetings) to communicate their progress and concerns to the scrum master. The application provides powerful story and task boards to help with managing and tracking sprint progress.

For details about sprint planning and using the planning board, see Sprint Planning.