How Velocity And Story Points Relate To Each Other During Sprint Estimation

What is “velocity” in scrum?

Velocity is a simple, yet a powerful and effective method for measuring, or adjudging, the rate at which the development team carries out and delivers work during scrum implementation. Velocity provides a reliable estimate, which indicates what the team is capable of in terms of developing requirements and delivering them in a successful manner. The development carried out should be “shippable” and have a certain monitory value attached to the functionality to be considered as “successfully completed”. Only “completed” or “done” functionality should be considered while calculating the velocity.    

How are velocity and story points related?

Velocity can be a useful tool while estimating how much, and how quickly, the development team can complete work. Scrum involves a lot of planning, in addition to setting up goals and targets. Once the product owner creates the product backlog, a list which includes all the requirements needed to develop a product in totality, it needs to be determined how long the development will take, or alternately in how much time the project can get completed. It becomes necessary for the product owner to provide an estimate to the stakeholders and the investors regarding when they can expect the product to be developed, and made available for selling purposes. This is where the problem comes in. How can the product owner calculate how much time will it take? 

The obvious answer would be to calculate the development in terms of working hours and provide an estimate based upon the total number of hours required to complete the project. However, each team member possesses a different capability while delivering work. An experienced developer or programmer might take two hours for a single task, while an inexperienced or novice programmer may complete the same task in eight hours. In scrum, the entire team carries out development. A single story may be broken down into several tasks, and each task may be given to different developers – both experienced ones and novice. It further complicates things for the product owner. A possible way out is to associate a certain type of measure which can ascertain the difficulty level associated with a user story, and carry out the estimate using that particular measure which is independent of working hours. The “measure” used for calculating the estimate is called a “story point” in scrum.

What exactly are story points?

In scrum, story points are an arbitrary measure, and used to determine or indicate the magnitude or size of an object, which is relative to a similar object. Story points are generally used to measure the user stories or product backlog items. Story points are used to estimate the development effort required for developing the features and requirements. For example, when a particular task may be associated with a story point, an experienced developer might find the task easy and associate five story points to the particular task. On the other hand, a novice programmer might find it very difficult and associate ten story points to the same task. This would create a discrepancy, since the task remains the same, yet its level of difficulty changes from person to person. In such a case, the scrum master considers the mean value, and allocates story points to the task. In the above case, the mean value would be ten points for the novice programmer plus five points for the experienced one divided by two (the number of developers associated with the task) which equals seven point five.

Level of difficulty	Story points	Mean value
Experienced programmer	5	(5 + 10) / 2
Novice programmer	10	7.5

Story points and velocity estimation

Once the product backlog is ready, the product owner starts assigning story points to the user stories in the backlog. He or she may also take the help of scrum master while determining and allotting the story points. Suppose the product backlog is assigned a value of three hundred story points - for the entire project to be developed. Now, the product owner calculates how much work the developers can take up on the basis of story points. An experienced programmer might be able to take up more work i.e. contribute more story points towards the development. Suppose he or she might be able to contribute fifteen points of work during the sprint. The novice programmer might contribute five points, while an intermediate programmer might be able to contribute ten points. Therefore, the total story points covered by the developers during the sprint can be summarized as:     

Experienced programmer	15 points
Novice programmer	5 points
Intermediate programmer	10 points
Story points covered by the programmers during the sprint	30 points

Therefore, work equivalent to thirty story points can be expected during one sprint. Since the project is worth three hundred story points, the total time taken is equal to:

Total story points associated with the project	300 product backlog points
Points covered during one sprint (On an average)	30 sprint points
Therefore, total number of sprints required	300 / 30 = 10 sprints
One sprint	2 weeks
10 sprints	2 x 10 = 20 weeks

As per the above calculations, it would take twenty weeks or five months, if we are to consider four weeks to a month, to complete the project. The estimation would be five months. 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!