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

Agile Development process flow

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

Agile Development process flow

Outlines the process flow for the Agile Development application from creating a product to the completion of a sprint.

The flow described here represents the common practice for creating and managing scrum records with the functionality provided in the base Agile Development. The flow is not intended to represent the only possible process. See Agile development use cases to review how different organizations use Agile Development application to deliver backlog or stories by different methods.

Watch this six-minute video for an introduction to managing Agile development in the Agile 2.0 application.

Task 1: Create a product

A product is defined as a set of features or functionality offered to users. For example, Time Entry can be a module offered by IT and HR department to all employees to record time for the work they do. Each product can have an owner that maintains the set of enhancement requests (stories) for the product. These stories can be organized under epics and themes. A product can have a narrow focus with few user stories or a wider context with many user stories, each containing several tasks.

Task 2: Create an agile group

A group of type Agile Team can be created and group members can be added to it. For each group member, the default number of story points that a member completes in a sprint can be defined. At the group level, the sum of the group member story points determines the group capacity.

Task 3: Create a release

Some organizations have a fixed time frame to release stories or features, which is referred as a release. For example, quarterly or six monthly releases. Releases are created by release or program management team and contain user stories, sometimes from multiple products that form the backlog. A release has a start and end date during which several development iterations are completed.

Task 4: Create a personalized backlog

A personalized backlog can be created by defining filter criteria. For example, one personalized backlog can be a combination of stories, defects, and incidents while the other personalized backlog can be combination of stories and incidents. In a similar manner, you can create as many personalized backlogs as necessary.

Task 5: Create a sprint

A sprint is the time frame in which development team delivers one or more stories. 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 for the group. A release can have multiple sprints in it. All sprints within a release must fit within the release start and end dates.

The assignment group is expected to complete all stories to which it is committed within a sprint. At the same time, the group should also 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 group, scrum master, and product owner.

Task 6: Plan the sprint

Before a sprint starts, the group and scrum master decide on what stories from the backlog they can commit to complete within a sprint. The scrum master must make sure that the effort (story points) required to complete the stories matches the capacity of the group.

Stories for a sprint can be selected based on priority. To plan the sprint-related activities, use Sprint Planning.

A velocity chart is available to help in the estimation process. The velocity chart shows historical record for a group of the number of completed points, by sprint. This view gives the scrum master an idea of the general capacity of the group over time and produces more accurate sprint planning. Velocity charts are most meaningful when sprint duration and number of group members are constant. Use the velocity chart as guidance and not as a factual representation of what the group can produce in the next sprint.

Task 7: Track a sprint progress

The scrum master manages the sprint team efforts, provides progress reports, and removes any impediments that the team encounters. 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 scrum master can track the sprint progress using Sprint Board.

Task 8: Track a release progress

The product owner tracks the progress of the release. Verifies whether the assignment group is completing stories and on track to achieve the release goal.

The product owner can use the analytics in the Home tab.