Avoiding Product Backlog Pitfalls – Get The Most Out Of Scrum

The product backlog is the heart of scrum in many ways. All the technical requirements needed to develop the product are included in the form of user stories in the product backlog. It is important that the product backlog item, or the user story, should be properly defined and narrated within the backlog. A product backlog item consists of several types of information, which actually define the exact requirement to be developed by the developed team during the sprint. It is very important that the product owner, the person who defines the user stories in the product backlog, avoid certain pitfalls, which can mess up the readability of the user story, or make it ineffective for development purpose.  
 

Creating the product backlog without any prioritization 

Estimation is an integral part of scrum, and burn down charts are created to reflect the velocity at which the team is currently carrying out the daily sprints. Estimation is possible only if backlog items are prioritized with user stories.
 

Creating the headline and not adding any explanatory description
Adding a title to mention the story name alone does not suffice. The team needs more information regarding the story to be developed.
 

Using less priority levels 

The user stories should include at least three priorities – high, medium, and low. Using only two priority levels such as “urgent” and “Later” fails to give a proper idea to the team as to how important the story is from the development point of view.
 

Committing the release date without prior communication
The team should be initially consulted and a release date worked out before apprising the stakeholders about the date.
 

Creating tasks instead of user stories
During the second half of the sprint planning meeting, the team segregates the user stories into individual tasks. The product owner should not define individual tasks in lieu of user stories in the backlog.
 

Long running sprints
The sprint should ideally last up to two weeks. If the cost effectiveness of product development is to be maintained, the sprint should be properly decided. It should not be too long so that feedback is availed after long intervals, and it should not be too short so that the team does not have enough time to develop the tasks. Both the aspects should be properly balanced.
 

Preparing a limited number of user stories
When the scrum project is planned, the product owner should create the entire product backlog. Creating a few stories to “start” the scrum process defeats the very purpose of implementing scrum, since proper estimation cannot be carried out, and velocity too cannot be determined in an effective manner.
 

Meeting only once a week
The product owner should be available as and when required by the team members and the scrum master. Meeting only once a week can prevent the team from proceeding with the development in case any problems are encountered during the sprint or additional information is required to understand the user story.
 

Answering your phone during the meeting
Perhaps the most irritating aspect is answering cell phones while a meeting is underway. It not only wastes time, but also breaks the concentration levels.
 

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

How Do Velocity And Story Points Correlate During Sprint Estimation

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.

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!

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! 

What Does Sprint Planning Consist Of And What Is Discussed And Finalized In It?

What is the purpose of a sprint planning meeting?

The basic purpose of a sprint planning meeting is to ensure that the development team can agree to a set of requirements or user stories extracted from the product backlog created by the product owner. The objective of the meeting is to make sure a suitable agreement is reached between the product owner, representing the interests of the stakeholders and the management, and the development team, regarding what needs to be developed during the sprint, and in what manner, based upon the priorities decided by the product owner. 

Many factors, including the velocity, or the rate and manner in which the team is capable of handling the development work, are considered while finalizing the sprint backlog, which is nothing but the list of development activities to be undertaken by the team during the sprint process. Care should be taken to include just the correct number of tasks, so that the entire sprint backlog is processed and successfully catered to at the end of the sprint, and the team members do not run out of work or user stories to develop during the sprinting process. Scrum levies a lot of stress upon successful completion of the user stories and the tasks when the sprint duration is completed.      

Who participates in the meeting?

Sprint planning is a joint, or a collaborative effort which involves:

• The Scrum Master – the person who facilitates the meeting.
• The Product Owner – the individual who clarifies the details associated with the product backlog items, and who also explains about their acceptance criteria.
• The team members – experts and professionals who carry out the development activities.

 

Before the meeting begins

It is important to plan, and to prepare for the sprint planning meeting. Before starting with the meeting:

• The product backlog should be properly defined and categorized by the Product Owner
• The user stories or the items mentioned in the product backlog should be properly prioritized and assigned a specific story point value by the product owner.
• The acceptance criteria should be carefully worked out and stated next to each user story.

 

What should the product backlog contain?

The product backlog can include new functionality, or a new set of requirements in addition to existing functionalities to be developed. The backlog should contain all the requirements, or the user stories required to develop the application or the utility in totality. Each requirement should be carefully segregated in a manner such that it is “shippable” when developed at the end of the sprint. 

New items may be added to the product backlog, or existing ones removed during the tenure of the project, depending upon the importance and priority of the functionality associated with the individual user stories. The decision to remove or add items in the product backlog is taken by the product owner, based upon the interests of the stakeholders and investors who host the project. 

Why is it required to “size” the backlog items?

Scrum implementation stresses that each item included within the sprint backlog should be successfully completed at the end of the sprint. In the event a particular user story remain incomplete, it should be ideally transferred back to the product backlog, so the product owner can re-evaluate its priority, and decide whether to include it again for development. 

Sometimes, a particular user story may be large, or very complex to be tackled “at a go”. It may prove to be very difficult to complete it during the sprinting process. It is for this reason that such user stories should be further broken down or split up into smaller parts so it can be developed in a successful manner by the team members. In such cases, the segregated user story may be allotted to different team members in the form of several “tasks” which are developed individually and independently of each other. It is for this reason that the backlog items need to be “sized” up at times.

 

Determining the capacity of the team to do work

The capacity, or the potential possessed by a development team to perform, or to do work, is obtained from three parameters obtained from each team member:

• The total number of working hours contributed by the team member.
• The total number of days the member will be available for the sprint activity i.e. if the member is going to remain absent for work.
• The total percentage of time and efforts the member will put in by taking up work i.e. how many user stories and tasks the member will take up.

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