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 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