When you’re working within the agile development process, the team’s goals and tasks are accomplished within a “sprint” framework. Simply put, a “sprint” is a designated amount of time – usually two weeks – where your team decides together what will be completed during that time. On the first day of each sprint — often a Monday morning — the scrum team holds the sprint planning meeting.
Very much a collaborative effort, the Product Owner describes the highest ordered product backlog items then the team determines and prioritizes what is necessary to complete those particular tasks. Team members volunteer to own the work and work owners estimate the ideal hours they need to finish.
Sprint Planning Meetings are made up of two different parts. Part 1 focuses on what the team is being asked to build and is attended by both the product owner and the team. Part 2 focuses on how the team plans to build the desired functionality. And, although the entire team must attend Part 2, attendance by the product owner is optional.
In Part 1, the product owner has the opportunity to describe a desired set of “stories” to the team. This is a deep-dive session on what the product owner would like to see developed. The product owner presents the stories, shows how things interact and walks through the interface. Additionally they may review infrastructure or architectural items. The goal is to inform the team with as much information as possible so they can determine how to best build the functionality. Types of questions typically asked include:
During Part 2 the team then turns its attention to building the “sprint backlog”. This is the list of stories and the tasks required to complete them during the sprint. To build the backlog, the team breaks down each story that the product owner has requested to the task level and then each task is given an hourly estimate. By the end of Part 2, the team decides which stories it can commit to completing during the sprint. Together, the two parts of the sprint planning meeting can take anywhere from two to eight hours.
Accomplishing what you set out to do
As long as the team leaves the Sprint Planning Meeting committed to completing a list of stories, the team has accomplished what they set out to do. Getting the team to the point where each team member feels comfortable making that commitment, however, requires a bit of pre-planning and facilitation.
The product owner must come to the meeting able to describe a set of desired stories. The team’s objective, then, is to understand the stories from the product owner’s point of view and share in the product owner’s vision. The ScrumMaster should ensure that the team is asking enough questions and capturing all of the resulting data, including acceptance criteria, sketches, and any assumptions. The ScrumMaster should also let the product owner know that the team might have additional questions after it begins to break the questions down into tasks. And finally, although the product owner presents stories s/he believe the team can complete within a given sprint, the development team will ultimately decide whether it can, in fact, take on all of the stories based on what it learns during Part 1 and Part 2 of the sprint planning meeting.
Here’s a sample Sprint Planning Meeting agenda
Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 3 - Sprint Planning Meeting - and be on the lookout for more videos in this series over the next few weeks
Very much a collaborative effort, the Product Owner describes the highest ordered product backlog items then the team determines and prioritizes what is necessary to complete those particular tasks. Team members volunteer to own the work and work owners estimate the ideal hours they need to finish.
Sprint Planning Meetings are made up of two different parts. Part 1 focuses on what the team is being asked to build and is attended by both the product owner and the team. Part 2 focuses on how the team plans to build the desired functionality. And, although the entire team must attend Part 2, attendance by the product owner is optional.
In Part 1, the product owner has the opportunity to describe a desired set of “stories” to the team. This is a deep-dive session on what the product owner would like to see developed. The product owner presents the stories, shows how things interact and walks through the interface. Additionally they may review infrastructure or architectural items. The goal is to inform the team with as much information as possible so they can determine how to best build the functionality. Types of questions typically asked include:
- “What is the acceptance criterion of all of these stories?”
- “What data sources do you think we are using?”
- “How should the interface look on this component?”
- “What are you expecting from the user experience?”
During Part 2 the team then turns its attention to building the “sprint backlog”. This is the list of stories and the tasks required to complete them during the sprint. To build the backlog, the team breaks down each story that the product owner has requested to the task level and then each task is given an hourly estimate. By the end of Part 2, the team decides which stories it can commit to completing during the sprint. Together, the two parts of the sprint planning meeting can take anywhere from two to eight hours.
Accomplishing what you set out to do
As long as the team leaves the Sprint Planning Meeting committed to completing a list of stories, the team has accomplished what they set out to do. Getting the team to the point where each team member feels comfortable making that commitment, however, requires a bit of pre-planning and facilitation.
The product owner must come to the meeting able to describe a set of desired stories. The team’s objective, then, is to understand the stories from the product owner’s point of view and share in the product owner’s vision. The ScrumMaster should ensure that the team is asking enough questions and capturing all of the resulting data, including acceptance criteria, sketches, and any assumptions. The ScrumMaster should also let the product owner know that the team might have additional questions after it begins to break the questions down into tasks. And finally, although the product owner presents stories s/he believe the team can complete within a given sprint, the development team will ultimately decide whether it can, in fact, take on all of the stories based on what it learns during Part 1 and Part 2 of the sprint planning meeting.
Here’s a sample Sprint Planning Meeting agenda
- Product Vision and Roadmap [Product Owner]
- Development status, state of our architecture, results of previous iterations [Team members]
- Iteration name and theme [ScrumMaster]
- Velocity in previous iteration(s) [ScrumMaster]
- Iteration timebox (dates, working days) [ScrumMaster]
- Team capacity (availability) [Team members]
- Issues and concerns? [ScrumMaster]
- Review and update definition of Done [Team members]
- Stories/items from the backlog to consider [Product Owner]
- Tasking out [Agile Team]
- Issues, Dependencies and Assumptions [ScrumMaster]
- Commit! [Agile Team]
Courtesy of agilemethodology.org, this series takes you through the lifecycle of a Sprint, from planning through to retrospective. Link to Video 3 - Sprint Planning Meeting - and be on the lookout for more videos in this series over the next few weeks
RSS Feed
