How is “velocity” understood in scrum?
The term “velocity” is
used to describe the pace, or the rate at which the development team members
carry out, and deliver work during sprint activity when scrum methodology is
implemented in a project. It is a simple, but power technique to generate a
reasonably reliable estimate about what the team is capable of doing, and the
rate at which it can deliver completed user stories at the end of the sprint.
It is important to know that the stories developed should be totally “complete”
and “shippable” to be considered for the estimation. User stories accepted as
“done” are included for the velocity calculation in scrum.
Why it is necessary to estimate velocity
Scrum includes a lot
of planning, and setting up of goals when it is to be implemented. The product
owner prepares a product backlog, which contains the list of user stories or
the requirements needed to manufacture the product. Once the list is prepared,
the person is required to give an estimation to the investors and stakeholders
as to how long the product will take to develop, and when it can be availed for
selling purposes. This is when an issue comes in – how can a proper estimate be
given regarding the product development?
In case of traditional development methodologies such as Waterfall, the estimate is generally given by calculating the working hours based upon the productivity delivered by individual team members. In case of scrum this is not possible, since the focus is upon the team as a whole. Individual effort does not count in scrum. It is what the team delivers as a whole unit which is more important. Moreover, team members possess varying levels of expertise. An experienced developer might complete a task in two hours, while a novice or an amateur might complete the same task in eight hours. It further adds on to the complexity of creating a trustworthy estimate.
In case of traditional development methodologies such as Waterfall, the estimate is generally given by calculating the working hours based upon the productivity delivered by individual team members. In case of scrum this is not possible, since the focus is upon the team as a whole. Individual effort does not count in scrum. It is what the team delivers as a whole unit which is more important. Moreover, team members possess varying levels of expertise. An experienced developer might complete a task in two hours, while a novice or an amateur might complete the same task in eight hours. It further adds on to the complexity of creating a trustworthy estimate.
What are story points in scrum?
To overcome this
problem, points known as “story points” are allotted to each user story based
upon its level of difficulty. Simple and easy stories carry fewer points while
difficult ones carry a higher weightage. A story point is an arbitrary number
value assigned to a story to indicate the complexity associated with the
functionality linked with the development. In simple words the story point
conveys how complex and difficult the particular requirement is. The story
point can be an integer, however it can also be fractional depending upon the
manner in which the complexity is determined for a particular requirement. For
example, an experienced programmer might find a particular task easy, and
assign five points to a story. A novice developer might find the task difficult
and assign ten points to it. So the user story can be associated with two
values depending upon who develops the story – five and ten. This is in
contradiction, since the story point should be a unique number. It cannot
assume two values. In such scenarios, the scrum master assigns a mean value of
the two numbers i.e.
Story points
|
|
Experienced
programmer
|
10
|
Novice programmer
|
5
|
Mean value
|
[(10 + 5) / 2]
(two programmers) = 7.5
|
The story point
value for the above example would be 7.5.
How are story points and velocity related?
Once the product backlog is created, the product owner is liable to provide an estimation
regarding the project completion. The person starts assigning story points to
the user stories contained within the backlog. He or she may also request help
or advice from the scrum master as and when required while assigning the
points. Once all the stories are linked up with appropriate story points, all
the points are added up to form a grand total. This total provides an idea how
big or large the entire project is. For example, a project may include user
stories which may total three hundred points. It becomes possible to create an
estimate once a grand total is available.
Product backlog
story points
|
300 points
|
Total number of
points which can be successfully developed by the entire team during the sprint
(Assume or suppose)
|
30 points / sprint
|
Therefore, total
sprints required to process the product backlog
|
300 / 30 = 10
sprints
|
One sprint lasts
for
|
2 weeks
|
Therefore, 10
sprints can extend for
|
2 weeks x 10
sprints = 20 weeks
|
The entire project
can be estimated to be completed in 20 weeks time.
Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!
