Move stories into team backlogs
Once your release backlog is defined and prioritized, you can assign (move) stories from the release backlog to a team backlog. Although this is an optional step, there are certain benefits to moving stories to teams before the sprint. In cases where the team may be working on stories from multiple products, they may need to organize or plan their work before the sprint to account for technical dependencies and other multi-product (or project) issues.
A highly self-organizing team can often add value by tasking out stories before they go into sprint planning, and estimating stories in their team backlog on a regular basis. It's important to note that all stories in a team backlog should be stories that are planned in a current or upcoming release. Because sprints are created as child-objects of teams, any story that is moved into a sprint is automatically moved into the team backlog by the system. As a rule of thumb, teams should become very familiar with stories in their team backlog before they get to Sprint planning. This not only helps their velocity over time, but ensures better stories are developed with a better understanding of business goals and quality.
You can drag-and-drop stories between backlogs. Use the CTRL key to select multiple stories before dropping them into a new backlog.
- Select the work item you want to move, click and hold down the mouse button.
- When you get the work item to the new backlog, release the mouse button.
- The backlog will refresh with the updated work item list.
Prioritize team backlog
Use release planning and sprint planning meetings to determine which stories should be moved into a specific Agile team's backlog. A team backlog should contain stories that will be committed to by a specific Agile team for an upcoming sprint. Stories in a team backlog should be well-written, have a high priority and a high business value. Stories in a team backlog should have an accurate story point estimate before being moved into a specific sprint backlog.
A work item in a team backlog can be moved to and from a release backlog (or another team's backlog) as needed, such as when business priorities change or when opportunities to create better business value arise. A work item in a team backlog can be added, edited, and removed as needed; however, any work item in a team backlog should have a high priority and a high business value.
Although managing team backlogs are optional, a team backlog may be prioritized by the team (with collaboration from the product owner) to account for technical dependencies and other factors that are unrelated to pure business priority. Note: When you are in the Backlog view, make sure your view-mode is set to List, so that you can stack-rank stories in relative priority. By default, the Backlog view will display stories in Tree mode.
You can prioritize a work item (sometimes called ranking a work item) in a backlog. Viewing a backlog in list view mode will ensure that you can view a work item by relative priority (where a higher rank equals a higher priority). (By default, Agile On Demand shows backlogs in the Tree view mode, which does not rank stories.)
- Choose a backlog.
- Click List.
- Choose the story you want to re-rank, select it (by holding down the mouse button), and then drag it to its new relative priority.
- When a work item is in the location you want it to be, de-select it (by releasing the mouse button). The backlog will refresh and the work item will have been re-ranked according to its new relative priority.
Estimate team backlog
Estimating a backlog is often done with the team during collaborative sessions where the the team provides technical input on the stories. Agile On Demand ships with a standard SCRUM configuration which allows estimation of stories by relative effort using story points (Fibonacci series of numbers).
Planning poker is a method of estimating the sizes of user stories during sprint and release planning meetings. Team members discuss a user story for a short period of time, after which team members assign that user story a points estimate. This is often done using Fibonacci numbers (1, 2, 3, 5, 8, 13, and so on), where the lower numbers are easier to work on. The team members with the highest and lowest estimates defend their positions, after which team members re-assign that user story a points estimate.
Velocity is a method of determining how many story points of work a team can commit to in a future sprint based on how many story points of work a team was able to complete in previous sprints. As a safe, general rule, a team should never commit to more story points in a sprint than their average velocity over the 2-4 previous sprints.