Sprint Planning

53 team-sprint-planning

Spring Planning is a fundamental mechanism for a team-oriented planning. Each Feature team member is given the power to estimate their capacity and commit to a feasible workload.

Explore More.

Related Mindset:

Lean-Agile

Segment:

Team

Inputs:

The team’s already established backlog stories, new stories that arise due to the context of the development process, defects, and any feedback from the previous Sprint Demo or Systems Demo

Outputs:

Sprint commitments for the iteration

Sprint Planning is an integral process for establishing the daily activity of a Feature Scrum team.

The team is given the authority to determine what they are capable of completing in the duration of the sprint. Each story is evaluated by its complexity, size, and dependencies. The sprint is fed one story at a time until the points approximately add up to the velocity.

For this planning to be successful, the team should have everything that is needed to properly estimate the functionality, including design, needed architectural runway, and business definition.

There are 5 steps to a successful Sprint Planning:

  1. Establish velocity: Each team member should call out any time off they are planning for. This is factored into the team velocity.
  2. Iteration goals: Typically, the product owner will discuss the goals of the sprint with the team.
  3. Estimate stories: The scrum master will open up planning poker and start pulling stories from the backlog. The team is given an opportunity to ask questions and raise flags in regard to the complexities and acceptance criteria for the story. Once the team feels they understand the story completely, a group vote is made to point the story. If anyone’s vote contrasts the rest of the teams, they are given an opportunity to articulate why they feel that way. The team is given an opportunity to recast their votes or adjust in consideration of team member(s) articulation.
  4. Tasks: Each story will require work from one or more team members. This work can be broken down into sub-tasks to help each team member know where and when they’re expertise should apply to the story.
  5. Commit: Once the team’s capacity has been reached with backlog stories, there is a final sign-off from the team. The product owner and team should have one last chance to consider the work that will be done for the current sprint. Once everyone gives a ‘thumbs up,’ the work is set in stone for the remaining two weeks.

Common Pitfalls

Sprint Planning is extremely important in the planning of a Feature team’s activity.

Through practice, the process does get easier. A few things to watch out for:

  • Over-estimating capacity: When estimating capacity the first time, there is no historical capacity to judge against. This can make the team feel uneasy, so it’s best to estimate a little light for the first sprint. Use that outcome to inform future capacity estimates.
  • Under-estimating story points: Some stories can turn out to be more involved than anticipated. It takes an experienced individual to foresee the potential issues that can arise during a development cycle. For these stories, it is best to overestimate the story points. If a team member runs out of work, there are typically backlog items or bugs that they can work on until the next sprint.
  • Old habits: Some stories may need to be compromised (within reason) to be completed in the sprint. It’s up to the product owner to determine what is acceptable. When this happens, an MVP (minimum viable product) approach should be considered, and an enhancement story should be made to accommodate a revisit. Waterfall does not allow for iteration and adjustments; agile does.
  • No User Experience (UX) runway: Sometimes business decisions are made late in the game. This can greatly affect the UX runway. When this happens, designers can block the developers and cause some friction in the beginning of the sprint. This is dangerous and requires the UX team to leverage each other’s knowledge and expertise to quickly and thoughtfully set expectations for when the work will be delivered.