Create a product

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

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

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 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

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.