This feature is available in all editions
Overview
In Agility, velocity is used when planning a sprint/iteration to ensure work is allocated consistently among team members. Velocity can be viewed at the sprint/iteration, team, and individual level.
In terms of reporting at the individual level, a number of measurements are available. You can report on a team member's estimated work, actuals, and estimation accuracy on a sprint/iteration by sprint/iteration basis within a project. You can also report on member history (e.g., actual effort) across all projects by day, week, or month.
Typically, you will see an individual's estimated and actual effort stabilize during a release (not on a task by task basis, but across all a person's tasks within a sprint/iteration), and therefore provide a very accurate gauge for capacity planning on a sprint/iteration by sprint/iteration basis.
You can use Agility's Capacity planning tools to capture the availability of each team member for a specific sprint/iteration.
Note that the Capacity Planning feature must first be enabled before use. Total Capacity displays in the Sprint Summary section of the Sprint/Iteration Planning and Sprint/Iteration Tracking pages and can be compared to Detail Estimate for planning purposes.
Tip
In agile development (Scrum, XP, etc.), resources are typically managed at the team level via the team's velocity. Velocity is simply the total of the estimated work delivered on a sprint/iteration by sprint/iteration basis. A team will generally build up a fairly stable velocity over the first several sprints, which can then be used for future planning purposes. Originally in XP, a person's individual velocity was also used for planning purposes, although most agile projects today plan directly from the team's ability to deliver.
In XP, for example, the team should not sign up for more than they delivered in the prior sprint (Yesterday's Weather), and in Scrum, the team signs up for whatever they believe they can achieve during the sprint, based on their experience. Typically, teams, when first starting out, will simply use a ratio of 1/3 to 1/2 of the total available hours in signing up for an early sprint in order to account for estimation error, meetings, admin, phone calls, emails, Q&A, etc. (i.e., non-production overhead).
Comments
Please sign in to leave a comment.