Learn the process that is used to manage product development efforts in Agile Development 2.0, such as creating a product or tracking a sprint or release.

Note: The flow explained here represents the common practice for managing agile development efforts using the functionality available in the Agile Development 2.0 application. This flow does not represent the only possible process.
Define products

A product can be a set of features or functionality offered to users. Each product can have an owner that maintains the work pipeline, such as epics and stories, for the product. These work items can be associated to a theme, which is related with a business goal.

See Create a product in Agile Development 2.0.

Create epics and stories

Epics contain high-level requirements for your products, which you can use to break down into manageable stories. While creating epics and stories in Agile Development 2.0, you can associate them with a product.

See Create an epic in Agile Development 2.0 and Create a story in Agile Development 2.0.

Create releases

Some organizations have a fixed time frame to make their products available to the market, which is referred to as a release. A release has a start and end date, during which several development iterations are completed. For example, you can have quarterly or half-yearly schedules to release new applications or enhancements to existing applications.

After you create a release in Agile Development 2.0, you can associate products, epics, and stories to it. See Create a release in Agile Development 2.0.

Create personalized backlogs

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 a combination of stories and incidents. In this way, you can create as many personalized backlogs as necessary.

See Create a personalized backlog in Agile Development 2.0

Create assignment groups

Create an assignment group add members to it. For each group member, define the number of story points that they can complete in a sprint. At the group level, the sum of the story points of all the group members determines the group capacity.

See Create an assignment group in Agile Development 2.0

Create sprints

A sprint is the time frame in which the 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 the number of sprints required for the group, and these sprints are used by the group members to complete the work required for an upcoming release. However, all sprints within a release must be within the release start and end dates.

Plan sprint activities

Before a sprint starts, the group and scrum master decide on what stories from the backlog they can commit to complete within a sprint. Stories for a sprint can be selected based on priority. The scrum master must ensure that the effort (total story points) required to complete the stories matches the capacity of the group.

While planning your sprints, you can use the velocity reports as guidance to estimate how much work the group can complete in the next sprint. The Agile 2.0 Team dashboard provides Velocity history report and Velocity by type report.
  • Velocity History: Gain an insight on the overall velocity of the team for the past 10 sprints. Analyze if the team is achieving a stable, predictable velocity, and is meeting the commitments.
  • Velocity by Type: Analyze the way your team's velocity changes over time and compare the team's strategic workload with operational or other types of workload.

For more information on how to plan your sprints, see Plan your sprint activities in Agile Development 2.0.

Track sprint progress

The scrum master manages the sprint team efforts, provides progress reports, and removes any blockers that the team encounters. Team members update story records and conduct daily standup meetings to discuss their progress and communicate the concerns to the scrum master and product owners.

The team is expected to complete all the stories that are committed for a sprint. The scrum master expects that the stories are fully tested and are ready for release, according to the acceptance criteria.

Ideally, the committed stories and the scope for a specific sprint should not change while the sprint is in progress. Agile Development 2.0 provides the flexibility to update as necessary and adapt to changing priorities. However, stories must be added or removed from a sprint only after a discussion between the group, scrum master, and product owner.

You can use the Agile 2.0 Sprint dashboard with reports such as burnup and burndown charts to track the progress of the team for a sprint.

Track release progress

The product owner tracks the progress of the release and verifies whether the team is completing stories in the pace that is necessary to achieve the release goal.

You can use the Agile 2.0 Release dashboard with reports such as burnup, burndown, and cycle time charts to track the progress of the team for a release.

Note: All Agile 2.0 dashboards are available with Performance Analytics Content Pack for Agile 2.0.