At the beginning of the sprint cycle , a “Sprint planning meeting” is held.

  • Select what work is to be done
  • Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
  • Identify and communicate how much of the work is likely to be done during the current sprint
  • Eight-hour time limit

o   PART 1 :  Entire team: dialog for selecting the Product Backlog which should go as part of this sprint. Basically the “WHAT” is decided in the first part of the Sprint Planning

o   PART 2 :  Development Team: hashing out a plan for the Sprint, i.e the HOW part

Product Owner and Sprint Planning Meeting

In Scrum, the sprint planning meeting is attended by the product owner, Scrum Master and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.

During the sprint planning meeting, 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. To make an example really simple, suppose a team always finishes five product backlog items. Their product owner should enter the meeting prepared to talk about the top 10 priorities.

There are two defined outputs that result from a sprint planning meeting:

  • A sprint goal
  • A sprint backlog

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. The following are example sprint goals on an eCommerce application:

  • Implement basic shopping cart functionality including add, remove, and update quantities.
  • Develop the checkout process: pay for an order, pick shipping, order gift wrapping, etc.

The sprint goal can be used for quick reporting to those outside the sprint. There are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item (user story) in detail. The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog.

The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.

An important point to reiterate here is that it’s the team that selects how much work they can do in the coming sprint. The product owner does not get to say, “We have four sprints left so you need to do one-fourth of everything I need.” We can hope the team does that much (or more), but it’s up to the team to determine how much they can do in the sprint.

Click here to watch our video on Inputs to Sprint Planning