Background

The dev team doesn’t deliver on time, software is late, buggy or just missing the mark in terms of features consistently month after month. The team is frustrated at management for frequently changing priorities, there’s lots of things that are half finished and the team feels overworked. These are all symptoms that Sprint Planning isn’t going well.

What’s Sprint Planning

Sprint Planning is the meeting where the team co-create an achievable plan for the work to be done by the end of the sprint. Sprint Planning is typically the first meeting of the sprint for teams practicing Scrum (for Kanban teams see Replenishment Planning)

If Sprint Planning is done well the team will end up with a detailed plan for the work that can be done during the sprint.

Attendees

Whole team, Product Owner and Scrum Master (Scrum Master facilitates the meeting)

Approximately 1 hour if Backlog Refinement has been done well beforehand, otherwise up to 4 hours.

How to run a Sprint Planning

  1. Prior to the meeting, run Backlog Refinement meetings or if you forgot run that meeting now
  2. Close the previous sprint and decide if the work not Done should spill over into this sprint or be done later. Don’t forget to split or re-estimate the remaining work on any stories that are partially finished (this allows us to correctly estimate our work for this sprint)
  3. Determine how many working days the team has for this sprint. For a 2 week sprint assume there are only 8 days (80%) maximum available to work and deduct any absences for leave, training etc. Total up the available working days for the team, it can help to use a spreadsheet for this to keep historical data.
  4. Using the team’s velocity chart for the past 3 sprints (the number of story points that were Done each sprint) and the teams working days for the past 3 sprints, predict the Target Velocity for this sprint. Use the average ratio of velocity per working day for the last 3 sprints and multiply it by the working days for this sprint to predict this sprints Target Velocity. This is easiest done on a spreadsheet
  5. Agree on the team’s Target Velocity and write it down using a Permanent Marker or somewhere everyone can see but nobody can change. (particularly don’t let the product owner change or influence this number, they will find it hard to resist)
  6. Pull stories from the Backlog into the Sprint until the Target Velocity is reached. Ensure that every story is estimated by the team prior to doing this, un-estimated stories are not eligible to be included in the sprint (be firm on this and it will save a lot of problems later)
  7. Check that no team member is over planned. Choose the team member that has the most story points allocated to them and ask them to re-assign the story to someone else or move the story back to the backlog. Pro Tip: Typically the best or lead developer will be over-allocated, however this is exactly the person that you want to be helping other team members do their work so ensure that the lead developer is well under-allocated and the whole team will be able to work faster. (this is also a good opportunity to cross-skill the other team members)
  8. Remove any stories from the sprint that are over the Target Velocity. At this point the Product Owner will usually complain and the team will say that they can work a bit harder and get it done, this is the world’s largest falacy! Never fix this problem by re-estimating stories or working harder. The developers have already underestimated stories (they always do, they are all optimists) and committing to do more work than is likely will just spill over to the following sprint making your long term planning useless.
  9. Take a team vote (scale 1-5) on how likely each person is to get ALL of their stories done this sprint. Find out what previously unmentioned impediments would prevent them and agree on how to mitigate them. Remove any work from the sprint where individuals are not 100% likely to finish it, see the point above and be ruthless on enforcing this as this is the exact practice that builds happy healthy and overly productive teams.
  10. Team formally commits to going their best to get each and every story done
  11. Start sprint, click the button in your sprint planning tool to start the sprint NOW. If you’re missing some stories, it’s too late they are not going to get done. Don’t leave this meeting until the sprint is started, all work has acceptance criteria, all work is estimated and there’s a goal for the sprint
  12. Team hold a half Standup (see Standups). It’s a “half standup” because there is no work done so far and if there are any blockers then we might need to revisit Sprint Planning again. It’s also a good time for the team to think about their first piece of work and get started.