Sprint Planning. What is it?
Sprint planning meeting is a core aspect in achieving successful implementation of a product in any Scrum organization.
In this article, we will talk about the Sprint Planning event (ceremony) in Scrum. As we know from the Scrum Guide, the work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.
The Sprint Planning meeting is a core aspect in achieving a successful implementation of a product in any Scrum organization. According to the Scrum Guide, the work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. In Scrum, the Sprint Planning meeting is attended by the Product Owner, the Scrum Master and the entire Dev team. Outside stakeholders or any others may attend by invitation of the team (for example to provide technical expertise or advices about security issues), although this is rare in most companies. During the Sprint Planning meeting, the Product Owner describes the highest priority features to the team. Also, during this event, the Product Owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the Product Backlog into the more detailed tasks of the Sprint Backlog. The Product Owner doesn't have to describe every item being tracked on the Product Backlog. A good guideline is for the Product Owner to come to the Sprint Planning meeting prepared to talk about two sprint's worth of Product Backlog items.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
The inputs to this meeting are:
Also, it is very important to have estimated capacity of the development team during Sprint planning and past performance of the development team (some think that it is not the input to the Sprint Planning, others think it is)
Usually, but of course not always (as it is not mandatory), the Sprint Planning consists if 2 part. In the first part of the event, the Product Owner as s/he explains the sprint vision and goal to the team. In the second part, the development team decomposes product backlog items, or user stories, into developable tasks for the daily sprint.
The first part: During the first part of the meeting, Product Owner shares the sprint vision with the team, and presents the sprint backlog containing important PBIs for development purposes. The Product Owner explains to the team what the proposed increment plans to deliver in terms of business value to the client, and how should the team develop the stories. The functionality desired in product features is also explained to the team. Perhaps the most important task of Product Owner during sprint planning events is to state and clarify the sprint goal in addition to the Definition of Done so the team can decide the development process and deliver potentially "shippable" product increments to the client.
The second part: In the second part of the Sprint Planning event the team meets to discuss how the PBIs should be decomposed into developable tasks. Stories are broken down into simpler, and easy to develop functional entities which can be developed independently of each other. Once this is done, the team decides which of the developers should take up which tasks. In scrum, team members have to pick their own tasks, or select them through mutual agreement. Developers generally choose tasks depending upon their levels of expertise and skill sets. Experienced developers may take up more complex tasks, while less experienced ones might select simpler features or functionality.
The Product Owner may, or may not attend this part of the event, but of course he or she has to be at this meeting and remain available if needed. If the team faces any problems, or has confusion regarding any activity undertaken in the upcoming sprint, it can request the PO to provide the answers.
There are two outputs that result from a sprint planning meeting:
A Sprint Goal serves to promote self-managing and creativity. It establishes the ‘why’ so the Development Team can work out the ‘how’. A sprint goal describes the purpose of a sprint. It provides a shared objective and states why it’s worthwhile undertaking the sprint. Sample sprint goals are “Learn about the right user interaction for the registration feature” and “Make the reporting feature available to the users”.
The sprint goal is a high-level summary of the goal the product owner would like to accomplish during a sprint, frequently elaborated through a specific set of product backlog items. A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.
A sprint backlog is the set of items that a cross-functional product team selects from its product backlog to work on during the upcoming sprint.
The Sprint Backlog is an ordered list of Product Backlog Items, preferably User Stories, that the Team believes it can complete during the coming Sprint. These items are pulled from the top of the Product Backlog during the Sprint Planning Meeting.
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
PMI ACP practice tests are the best opportunity for you to prepare for the Agile certified exam. There are 540 questions: 1 FREE assessment (80 questions), 4 mock tests (120 questions) and 1 mock exam (120 questions randomly selected out of 540)