<img height="1" width="1" src="https://www.facebook.com/tr?id=2077527452260672&amp;ev=PageView &amp;noscript=1">

Sprint Planning Meetings

In SAFe Scrum, each iteration cycle begins with a Scrum planning meeting, which is also known as a “Sprint planning meeting.” In this  meeting, the Product Owner and the Agile Team select user stories from the product backlog for development purpose. The meeting is time boxed, and can last from four to six hours depending upon how many stories have to be selected, and how much time the team takes in distributing the tasks amongst themselves.

Purpose of Scrum planning meeting

We do  Scrum planning meeting  basically for discussion between the Product Owner and the Team members. The main intention of holding the sprint planning meeting is to select product backlog items having high business values from the top of the product backlog. High priority stories are carefully chosen and put into  the sprint backlog for development purpose. SAFe Scrum suggests that product features which have more importance in terms of their Business values should be developed first, followed by less important ones. This is usually done to ensure that the value of the project does not reduce over time.

IMG_0012_1.jpg

The Product Owner  is completely responsible for delivering a project having a certain business value to the stakeholders. This is possible when the product features and functionality have a certain financial “worth” in the market based upon how important they are from the end users point of view, and how much the end users are likely to pay for using them. Therefore, the PO selects high value user stories to maintain the project value at all times, even while the product is currently being developed.

Accepting and rejecting user stories during the meeting

While the Product Owner  is completely responsible for delivering a project having a certain business value to the stakeholders, PO can suggest high priority user stories to the team, but the team has the complete “right” to “accept or reject” them after giving valid reasons regarding its decisions.A user story may not be defined properly, or the team may fail to understand the acceptance criteria associated with a story.

The PO is held responsible for the creation and upkeep of the product backlog. Therefore, the PO also oversees the backlog refinement process. In such cases, the team can inform the PO to update the particular story and “reject” its development for the time being. Stories or product items are added to the sprint backlog only after they are approved  by both the PO and the Agile team members.

Manual vs. Computerized Agile boards

If the Agile Team is using manual Agile methods to develop the project, user stories can be “selected” by “pasting” index cards on the Scrum whiteboards. Each index card represents a unique user story. The board may be divided into three columns - “To Do”, “In Progress/Doing”, and “Completed/Done” – to indicate the current sprint status.

IMG_0147_1.jpg

As stories get completed, they are moved from “To Do”, to “In Progress”, and finally in the “Completed” section of the whiteboard.

IMG_5840_1_1.jpg

Teams using electronic or digital Scrum tools have a “virtual” whiteboard, which generally keeps on updating itself as and when sprint backlog items are created, and user stories are completed. 

Sprint planning meeting trends in current world

 

Traditionally, the Product Owner was sole responsible to decide which stories could be completed from the product backlog and transfer the same to sprint backlog for development purposes. Nowadays, the sprint planning meeting has evolved to become a “single” Scrum event, and the role of the PO too has changed. Rather than the PO deciding which stories to pick, the entire team takes an active part in the decision process, and then  team decides jointly with the PO which stories should be selected and how the sprint backlog should be created.


Like this post? Share it with friends