Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.
  • Madrid
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store

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.

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 that is referred as Product Backlog. 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. You create products first and then add themes, epics, or stories to create the product backlog.

Task 2: 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 reader understand what the product should accomplish. 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.

The product owner maintains the product backlog and grooms it by adding new stories or detailing the existing stories.

Task 3: 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 4: Create a release

Some organizations have a fixed time frame to release stories or features, which is referred as a release. For example, a 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 release backlog. A release has a start and end date during which several development iterations are completed.

Task 5: Plan a release

After a release record is created, perform release planning by selecting a product and moving stories from a product backlog to a release backlog. This creates a release backlog. Optionally, you can assign them to an appropriate group simultaneously, which creates a group backlog too.

Stories for a release can be selected based on story ranking. Ranking enables to manually sort a list of stories by priority.

A product owner may assign a few similar stories from the release backlog to a specific project (having an agile phase) and execute them as part of project.

Task 6: Create a sprint for a group

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.

The Agile Development application provides the facility to generate sprints for each group.

Task 7: Plan the sprint

Before a sprint starts, the group and scrum master decide on what stories from the group 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 ranking. Use Sprint Planning board in Agile Development application to plan a sprint for a group.

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 8: 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 Agile Development application provides powerful story and task progress boards for group members to help with managing and tracking sprint progress.

The scrum master can also track the sprint progress with the scrum master dashboard.

Task 9: Track a release progress

The product owner tracks the progress of the release using the product owner dashboard.

Task 10: Generate charts

In addition to the progress boards, Agile Development provides a report known as a burndown chart for tracking the progress of a sprint. This chart is one of the most important tools of a scrum team.

The burndown chart compares ideal progress in a sprint (based on the committed stories) against the actual progress, daily. This report enables the scrum master and group to track progress and make necessary adjustments to complete the sprint on time.

See Agile development use cases to review how different organizations use Agile Development application to deliver backlog/stories by different methods.