Sprint Planning

Do you want to plan your Sprint effectively?

Sprint planning meeting is a time-boxed working session that lasts roughly 1 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items within a Sprint. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

Meeting Specifics

Time-box:

  • 4 hours for 2 weeks sprint or 8 hours for 4 weeks sprint

Attendees:

  • Scrum Master: who facilitates the meeting.
  • Product Owner: who clarifies the details of the product backlog items and their respective acceptance criteria.
  • Development Team: who defines the work and effort necessary to meet the sprint commitment.

When:

  • Before starting with a new sprint.

Inputs:

  • Product Backlog
  • Team Capacity

Outputs:

  • Sprint Backlog: 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.
  • Sprint Goal: 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.

Sprint planning process:

  • Establish goals for your sprint.
  • Choose the user stories that support those goals.
  • Break user stories into specific development tasks.
  • Create a sprint backlog.

Prior to Sprint Planning Meeting:

Prior to sprint planning, the Product Owner identifies the items with the greatest value and works towards getting them to a ready state. The development team tries to understand the functionality and technical aspects of user stories to be included in the sprint.

  • Assign a relative story point.
  • Remove dependencies.
  • Create testable examples.
  • Define acceptance criteria.
  • Meets INVEST criteria

Why sprint planning is important?

The idea behind the sprint planning is to provide understanding between development and the customer (or PO) when something new (and working) will be available, and to define the length of the feedback loop, which equals to the length of the sprint. In other words, the customer will know that He/she will get something in 2 weeks, which works, and the development team will know that they’ll receive feedback on their work and know more about the upcoming work in two weeks. That’s predictability.

Tips for effective sprint planning meetings

  • Remind the team of the big picture or goal.
  • Discuss any new information that may impact the plan.
  • Present the velocity to be used for this release.
  • Confirm team capacity.
  • Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint.
  • Presently proposed product backlog items to consider for the sprint backlog.
  • Determine the needs, sign up for work, and estimate the work owned.
  • Product Owner answers clarifying questions and elaborates acceptance criteria.
  • Confirm any assumptions or dependencies discovered during planning and record.
  • Scrum Master calls for a group consensus on the plan.
  • Team and Product Owner agree upon the best plan they can make given what they know right now.
  • Get back to work

Do you want to plan your Sprint effectively?