Before an organisation goes Scrum, they're most likely to be following a waterfall paradigm and using Function Points, Lines of Code (LOC), Analogy, etc., for software estimation in hours per task. They'll probably also use Earned Value or Microsoft Project as a means to measure their progress and ultimately, their profitability. In Scrum, story points are generally used as the estimation mechanisms and Velocity is used to measure progress and, indirectly, profitability.
Velocity In Hours
If the Scrum development team chooses to use hours as their estimation mechanism then velocity is easily arrived at: (number of team members * effective hours/day) * number of days in sprint. Using hours has a certain appeal to teams unfamiliar with Scrum and story points but using hours implies a estimation precision that simply doesn't (and never did) exist. Another issue with using hours is the 'User Stories' can read more like the waterfall-ish requirements that preceded them and be of a technical nature. Although these may capture the basic functionality, they may fail to grasp the end users' point of view, give little or no hint of usability, and tend to read like development tasks; telling the development team how to implement the feature.
Unlike estimating in hours, story points are at best only an approximation of the effort required. The Scrum Master should steer the team toward using story points as soon as practical.
Velocity In Story Points
Prior to the first sprint, have the development team define a reference user story. A reference user story is one were the entire development team can reach an agreement on the effort involved in developing the feature, the complexity of developing it, and the risk inherent in it. This can be one of the user stories the product owner has written for the team or can be some small bit of previously implemented functionality that is familiar to the team. In either case, the reference story is usually something that can be completed by the whole team within a day or two. Once the reference user story is established, give this story 2 story points. All other user stories are estimated compared to this 2-point reference story. A story that is assigned a 4 should be twice as much as a 2-point reference user story. A story assigned 1 is one-half as much as the 2-point reference user story. The actual length of time eventually becomes unimportant. Planning Poker is probably the best estimation technique to use when estimating user stories.
All stories considered for the first sprint are estimated by comparison to the reference story. The team selects and estimates stories they believe can be completed to the satisfaction of the team's Definition of Done in the first sprint (see Definition of Done: How to Ensure Compliance). The total count of story points becomes the team's initial estimated velocity.
Velocity Is For The Scrum Team
Once the team has arrived at an estimated velocity, the Scrum Master can then begin using this as a KPI for the team. However, care should be taken to ensure that velocity is not used to compare between teams (see Velocity as a KPI in Scrum). The Scrum Master can track the team's velocity and over time, measure the team's performance (see Increasing Velocity Vs Stable Velocity).
