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. During the scrum process, 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!

How Product Owners Can Increase Their ROI And Boost Up Sales

Many discussions and talks have been carried out regarding the actual role of a product owner i.e. what makes the ideal product owner. Several suggestions have been put forward explaining the role of the product owner – both ideal ones and practical ones. However, the debate is far from over since client requirements often keep on changing, and there is always a confusion whether a client can assume the role of a product owner, and if so, would it be contradictory to scrum methodology? Actually, it would be more meaningful to consider what type of activities should be undertaken by the product owner, rather than follow the ideal role of being one. As far as real life scenarios are concerned, it is the client who is the most well versed person as regards the developmental requirements and what kinds of functionalities ought to be incorporated in the user stories.
 

Know more about the Product Owner’s role at Quickscrum!
 

Suggested activities for a product owner
For the client and the product owner, it is very important to be familiar with the scrum methodology and its techniques. It is also important to know about the advantages of scrum, and what it has to offer over traditional development methods before tapping the full potential of it. The activities can ideally include:

• Remain present and contribute information as well as knowledge during sprint reviews, sprint planning, and retrospective meetings
• Order and create the product backlog based upon the importance of user stories and ROI
• Be easily available to team members, and provide appropriate feedback whenever they face difficulties or issues during development
• Thoroughly understand the product backlog items, and define the acceptance criteria for the tasks.   
• Define a sprint goal for each sprint
• Not try to influence the mindsets of team members with regards the complexity involved with the development activity, rather encourage them to be productive and “open to problems”
• Respect and adhere to the sprint goal

 

How product owners can make their work easy and more productive
It is very important to correctly define and manage the product backlog items to implement scrum in the perfect manner, and benefit from the advantages offered by the methodology. In addition, the user stories need to be properly stated and identified within the system, and individual tasks taken up by the team members. QuickScrum helps to define product backlog items with a lot of ease and flexibility, and what’s more, the items can be effortlessly rearranged as per choice using dynamic drag-and-drop features. You can save a lot of valuable time and efforts while allotting tasks to individual team members, and check out the project status using highly informative and useful reporting capabilities included within the scrum management tool. QuickScrum supports a host of useful and dynamic features specially developed for product owners, scrum masters, and businesses using scrum methodology to increase their productivity. It’s worth knowing more about this flexible and powerful scrum management tool, and the plethora of time saving and productivity-increasing features specially developed for you.
 

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