What is sprint planning?
Thu 02 Apr 2015 00:09
In Agile Scrum, every iteration cycle begins with a sprint planning meeting. The primary reason for undertaking sprint planning is to create the sprint backlog – a temporary list of user stories having high “business value” selected from the product backlog - for the development team to work upon during the daily sprints. Traditionally, the sprint planning meeting was held in two parts. However, Scrum has now evolved, and the sprint planning is a “single” event now.
What is sprint planning? To understand the process in a nutshell, in the Agile process, development is carried out in short “bursts” of activity through product incremental cycles known as sprints. A small “portion” of the product backlog, i.e. the user stories defined in the backlog are carefully selected by the product owner and “transferred” to a temporary list known as a “sprint backlog”. The development team processes the sprint backlog and develops the stories contained therein during the daily sprints. At the end of the sprint cycle, fully developed, tested, and deployable “development” is presented to the PO for verification purposes. The event specially dedicated to the sprint process is the sprint planning meeting. The event is time-boxed from six hours to eight hours max. It should not exceed more than one working day.
The sprint planning process
Traditionally, the sprint planning process was carried out in two parts. The first part used to be “dominated” by the product owner, while in the second part the team members used to distribute “work” amongst themselves.
The objective of sprint planning is to select user stories for development purposes. The product owner carefully selects a few product backlog items or user stories having high “market value” from the product backlog. These stories, or product features, are transferred to the sprint backlog. The development team picks up stories, one by one, and distributes them for development purpose. When the PO selects the user stories, the development team negotiates with the product owner as to which of the stories are “developable”, and which of them cannot be “accepted”. The team has to give reasons if a particular story is not developable. The PO argues why the team cannot develop it, and genuine “reasons” are identified. If the acceptance criterion is not properly defined, or the story is not described in a clear manner, the team can reject the story. In such a case, the PO has to ensure that the story is “updated” with new or additional information and made “ready” for development purposes. Development can take place only after this is done. In the end, a sprint backlog is created, and accepted by all.
Once the sprint backlog is finalised, the development team starts analysing the product features taken up for development. Each feature is further divided into “developable” parts and distributed amongst the team members based upon their levels of expertise and experience. Experienced programmers may take up complex or lengthy stories while less experienced ones may settle for less complex and simple user stories. The distribution process is carried out as per mutual consent. The team members have to collaborate and decide amongst themselves as to how the developments tasks should be ideally distributed. Developers can also “volunteer” to take up certain stories on their own if they feel they can handle the development independently. If there is a confusion regarding the acceptance criteria or if the story is still not clear, they can summon the PO for additional explanation. Stories taken up for development in the sprint backlog have to be completed by all means and cannot be transferred back to the product backlog. As per recent Agile trends, the actual sprint planning process has become more collaborative, and the PO tends to “share” his or her thoughts regarding which of the stories should be taken up for development. Even though the PO has the final say regarding the selection, the team members are encouraged to participate in the selection process and “help” the PO in picking up user stories from the product backlog. The entire process concentrates more upon teamwork. Emphasis is given upon “tackling” development as a cohesive unit rather than remain concerned about individual contributions. Agile supports and encourages teamwork and team efforts over individual contributions.