This feature is available in all editions.
Within VersionOne, 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 VersionOne's capacity planning tools to capture the availability of each team member for a specific sprint/iteration.
To learn more, see Capacity Planning is accessed via Sprint Planning --> Capacity Planning. This feature has to be enabled through the Administration --> Configuration --> System page. Total Capacity within Sprint Planning and Tracking will display in the Sprint Summary section and can be compared to the Detail Estimate for planning purposes.
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).