Modules and Views → Home → Guidance → Allocate Work to Teams
Teams frequently commit to more than one story per sprint, but it is important to understand that the effort required to complete the work required by a single story (including all of its related tasks and dependencies) is done in a single sprint by a single Agile team. Some assignments (like tasks) are identified before the sprint begins, while others (like defects and impediments) are discovered during the sprint.
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.
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, Serena Agile Planner shows backlogs in the Tree view mode, which does not rank stories.)
Estimating a backlog is often done with the team during collaborative sessions where the the team provides technical input on the stories. Serena Agile Planner 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.