Thursday 27 March 2014

What Agenda Should An Ideal Sprint Planning Meeting Follow To Be Effective?



The sprint planning meeting plays a very import role during scrum implementation. It precedes the actual sprinting activity, and is attended by:

  • The scrum master
  • The development team members
  • The product owner 

The stakeholders or the people investing resources into the project may also attend the meeting if they desire to do so. The meeting is ideally scheduled to last for eight hours. On the day the meeting is to be held, the product owner comes to the meeting prepared with a well-organized and prioritized product backlog. The backlog may contain user stores and tasks, as is generally the norm, however it can also just contain a list of requirements as decided by the product owner. 

The product owner represents the interests of the management and the stakeholders, and possesses knowledge as to which requirements are more important, and how much weight they carry in terms of development. He or she prepares the product backlog on the basis of the priorities associated with the user stories or the requirements.

Agenda of the sprint planning meeting
The sprint planning meeting is generally held in two parts.

The first part of the sprint planning meeting
The agenda followed during the meeting is simple and straightforward – in accordance to the guidelines specified by the scrum guide. Few simple but important activities are carried out as per the agenda.


• If the project is new, or if the sprint is to be carried out for the first time with respect to the current project, the scrum master introduces the development team members and explains about the roles they are likely to play with regards the development activity during the sprint.


• The product owner states and outlines the goals associated with the sprint, and what the sprint should ideally accomplish at the end of its iteration.
   - The product owner may also offer additional details and explain how the user stories are important from the stakeholders point of view, and why they are so prioritized.
   - The team members have an opportunity to ask questions and seek clarifications about points which they are not clear about. They may also ask questions regarding the goals set up, and may ask for additional details concerning the acceptance levels and criteria specified by the product owner and the stakeholders.


• The product owner reviews the entire product backlog, and discusses about the priorities associated with the user stories contained therein.
   - The team members may ask questions pertaining to the scope of each user story. This would help them to segregate the user stories into individual tasks later on when they process the sprint backlog for development purposes. 


• After the product backlog is carefully explained, and all relevant discussions are carried out, the product owner may excuse himself or herself and leave the meeting. The person is, however, liable to make himself or herself available for the entire day to answer questions and provide explanations for queries as and when they are presented by the team members or anyone associated with the project and is attending the meeting.  


The second part of the sprint planning meeting
During the second part of the meeting, the development team members start processing the sprint backlog. A sprint backlog is the set of requirements or user stories selected by the product owner from the product backlog. The sprint backlog contains only those stories which are to be developed during the sprint activity. Typically, the team members break up, or segregate the user stories into individual development tasks. These tasks are subsequently taken up, or accepted by individual team members for developing reasons. However, before doing that, the team carries out planning activities, and tries to arrive at proper estimates as to how much time each task will take, or consume, to be developed in totality i.e. how much time each task will take to develop completely.

The team may employ any of the several methods available as to how the sprint backlog should be processed for development purposes. One of the commonest methods, also advocated by the scrum guide, is to first take up tasks which are more important, and which carry more “value”, followed by other tasks which are of lesser importance to the stakeholders. The team tries to arrange or complete the sprint backlog in accordance to how many tasks each member can process, or carry out, during the sprint. It is important to successfully complete all the tasks narrated in the sprint backlog. 

Ideally, no tasks should remain pending at the end of the sprint. The members should use their experience while taking up the development tasks. They should not take up additional tasks which they may fail to complete at the end of the sprint. At the same time, they should not take up fewer tasks, so they run out of “work” during the sprint activity. It is imperative to balance both the aspects – take up enough work so that it lasts the entire duration of the sprint, and complete the work in totality at the end of the sprint. The task and user stories developed at the end of the iteration should be “shippable” and have a commercial value attached to them.  

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

No comments:

Post a Comment