Sprint Planning

This is the meeting where all the people who are interested in the product development will be participating. The meeting is split in to two parts. During the first part of the meeting the Product owner pulls out the user stories from the product backlog and will start explaining about his expectations out of each user stories. This is where the team has to ask number of questions to clarify about the user stories. The team is encouraged to ask all the questions that would help them in understanding the user stories in a lucid way. More the questions the QA team asks more clearly the developer would understand about the user story. It would also help the QA make good test coverage while writing the test cases. The user stories pulled in for the new iteration may vary from any kind of new development to bug fixing. But while deciding the user stories product owner should keep in mind about the team’s velocity and the team’s availability in mind.


It’s always a good idea to ask about the team’s availability at the very beginning of the sprint planning meeting.During the second part of the meeting the scrum team pulls out the story that was decided to work on the current sprint. Each story is then divided into many tasks based on the discussions between the developers and the testers. Separate task is assigned for the tester under the same story. It is better not to include the automation testing task along with the manual testing tasks. If team feels that there is difference between the story points after putting all the tasks together, poker can be used to estimate the story points. The granular breaking down of stories into tasks should be done by the team rather than any individual like managers. It is the team that has to decide during the stipulated amount of time. Rather than the managers, the best people to decide what can be done during the time boxed are the people who are going to do it [Ken Schwaber]. When the team decides what to do, it’s pushed indirectly to make an open commitment which it will strive to make it DONE.

The artifacts that would arrive at the end of the sprint planning meeting would be [1] Sprint Goal [2]List of user stories and tasks that are committed for the sprint put up in a document or any kind of scrum tool that is visible to the team and the management.

  

The common mistake that the team makes during the estimation is that the team always thinks in positive way and it tries to pull out maximum number of user stories. The scrum master should always help the team in picking up “Just Enough” user stories. Also while planning the, the stories and the tasks should be made in such a way that some kind of working demo can be given whilst the story is closed. Also keeping more tasks in a story makes the story to be in the open state for a long time during the sprint. So the scrum team has to make sure that there are only “Just enough” tasks for a user story. It always makes the developer/tester happy when some story gets closed during the sprint.

Advertisements
This entry was posted in Agile. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s