Effective planning of release and sprint backlogs involves assigning the right amount of work items for the release capacity.
To facilitate this, each team is assigned a sprint velocity, which determines the overall release capacity. At the other end of the equation, the size of each user story and defect is estimated in story points. After completing these estimations, you can create an optimal release and sprint work plan.
The expected sprint velocity is the estimated number of story points a team can deliver in a sprint. Each team has a different velocity. The team velocities contribute to the following Agile Manager measurements:
- Sprint velocity. The velocities of all the teams participating in a sprint determines the sprint velocity.
- Release capacity. The velocities of all the sprints determines the overall release capacity.
The sprint and release capacities serve as guidelines for the amount of backlog items you can plan to each release, sprint, and team.
After a team has participated in several sprints, use Agile Manager widgets to analyze the amount of story points the team managed to deliver. Based on this historical data, you can reevaluate the team's expected velocity for future sprints.
Note: Team velocities are set by administrators on the team details page in the configuration area.
Each backlog item – user story or defect – differs in size. In Agile methodology, you estimate the size of backlog items in story points. The amount of story points you assign to a work item denotes its size relative to other work items.
Optionally, an organization can decide to use story points as absolute values. For example, you could define that a user story with one story point requires one day of work to implement.
Note: Agile Manager notifies you if a backlog includes items that do not have a story point estimation.
Assign work items to the release or sprint backlog to fill the available capacity. Agile Manager graphically displays the amount of free space in a backlog, and warns if a backlog exceeds the capacity.
If a backlog has exceeded its capacity, use the following methods to balance the workload:
- Unassign user stories or defects from the release or sprint.
- Break large user stories into parts, and leave only a part in the current backlog.
- If feasible, increase the teams' velocities.
Breaking a user story is useful for dividing a large user story into two or more smaller parts. You can postpone some of the new stories to later sprints or releases, and assign them to other features.
- Select a user story, and click Break Story.
- In the Break Story dialog box, define parts that constitute the original user story, and assign story points for each new story.
- Click Finish. The new stories are added to the backlog.
The original user story becomes a group story. Use the Group Story View on the Product Backlog > Backlog page to view the group story and drill down to its children. Each child story is linked to the parent group story (for user stories broken in
March 2017or later).
The new stories inherit the original story's tasks, acceptance tests, and entity links.
Story points assigned to the original user story are removed. The group story's story points are the sum of the story points assigned to the new user stories.
Note: You can continue to break the new user stories into lower-level parts. These are all maintained under the same hierarchy as the original user story.
If a sprint or release is over-planned, you may want to increase its capacity. The sprint and release capacities are derived from the estimated sprint velocities per team, as defined in the team settings pages.
To adjust a team's sprint velocity:
On the Product Backlog or Release Backlog page, in a release or team bucket on the right, click a capacity information link .
Examine the actual velocity in previous sprints and the average velocity.
In the release capacity or team velocity dialog box, use the bar chart to examine the expected and actual velocity in previous sprints, and compare them to the average velocity.
Hover over the bars to view exact numbers.
If the average velocity is greater than expected, consider increasing teams' estimated velocities.
If you're on the Product Backlog page, click the link on the bottom to the team settings page, and modify the velocity for the specific sprint there.
If you're on the Release Backlog page, you can modify the team velocity directly in the dialog box, by double-clicking the number in the Expected Velocity column. The bar chart adjusts accordingly.