How Should A Sprint Plan Be Made?
Sprint planning is a set of activities enabling product requirements submitted by a Product Owner to be met within 2-3 weeks periods. During planning process Product Owner, Scrum Master and Scrum Team attends to Sprint Planning Meeting. In general, these meetings are hold in two sessions, one of which is a kick-off meeting, Product Owner’s explaining the requirements to team, and the other is team breaking out and estimating tasks.
Product Owner should attend to the first meeting by gathering user stories, requirements and organizing them as a product backlog. In the meeting, Product Owner outlines goals clearly for the sprint and explains his expectations. It is significant that Product Owner should review the product backlog with the team and get approval for their understanding the scope. On the other hand, the team also should ask detailed questions about the scope of each story in order that they can break user stories into tasks later on easily. Other significant point is defining acceptance criteria during the meeting.
In the second session of the Sprint Planning Meeting, team discusses on information submitted by Product Owner in the first meeting. Team members work together to break user stories into tasks and estimate durations of each task. In order to facilitate estimating team can use a game called “Planning Poker” in which a number is associated with each task to indicate how big or small it is. Usually the team determines tasks and at the end of the Sprint Planning Meeting they develop the Sprint Backlog by considering priority and capacity. Since determined tasks are accepted as a commitment, the important point is deciding how small a task can be broken down and how consistent these tasks with the sprint score goal. As an illustration, a team is given a goal to complete 10 tasks in a 2 week sprint and team members break user stories into very small tasks / subtasks, it can show the success of the team higher at first, but it is not appropriate to measure the velocity and giving forecasting information for the following sprints. Breaking down into and defining tasks correctly are resulted from understanding user stories well and forecasting team velocity by using previous data.
The success of sprint planning depends not only applying required steps in meetings, but also solving encountered problems such as Product Owner’s not preparing for the meeting or submitting his requests only via written communication means, not defining acceptance criteria well, Product Owner’s attempting to change duration estimations. Scrum Master ought to interfere such issues and give information about Scrum techniques to Product Owner if necessary. Particularly, organization which newly adopting Scrum techniques need Scrum Master’s support to both Product Owner and team members until everyone interiorizes these new methods.