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!