Scrum Beginnings (Part 9): Your First Sprint Planning!

White Board with Post-It Notes and other Writing

At this point during your first few days as a new Scrum Master, you have begun getting to know your team, set up a few introductory meetings, a team working agreement, agreed on a definition of “ready” and “done” and set up your sprint ceremonies. With those first few agenda items, you will have begun laying the foundation for a strong Scrum team.

Let’s say at this point, your Product Owner has also finalized the initial backlog for the first sprint. The team has helped groom the stories and they all meet the “ready” criteria. Despite the whirlwind of the first week, you are ready to have your first Sprint planning meeting! As you begin to review all the theory from your favorite Scrum books, you realize you are actually pretty terrified about how to efficiently run the meeting. After all, besides that mock sprint planning meeting at your CSM workshop, you may have never actually run a real planning before. But have no fear, your favorite Scrum Master is here! Here is how I run my planning meetings from start to finish!


I like to hold my sprint planning meetings first thing in the morning on the first day of the sprint so that we can immediately get to development after the meeting. Typically, I will start off the planning by reviewing which stories got carried over or split from the previous sprint. This will help the team visualize what work they were not able to complete and thus help everyone plan accordingly as they begin pulling in stories from the backlog. We use a project management tool called CA: Agile Central or “Rally” to keep track of our work from sprint to sprint. There are many great options in the agile world, so hopefully my workflow will make sense for any product that you happen to use.

Team Capacity

Before we can start tasking out stories, we need to know how much capacity every team member will have that sprint. The simple way we calculate this is by starting with the number of realistic work hours in a two week sprint (10 days x 6 hrs) = 60. We use 6 hours as an average daily workload since we account for lunch and any other distractions that pull you away from your work. We have each team member count up how much time they will spend in planned meetings, days off or time out of the office. We then have them subtract that from 60 and that will give each of them their capacity for the sprint. Each of the team members put that number into Rally so that as they assign tasks to themselves, we can get an idea of whether they will be taking on too much work.

Commit to a Velocity

Everyone on the team now knows how much time they will be able to devote to their development work, so now it’s time to commit to a velocity. If you are a brand new Scrum team, you will have to guess, since there is no historical data to give you an approximation. This is one of the trickiest parts of Scrum, so don’t worry about being completely off during your first few iterations together. With my team, we like to use an average of 5 points/developer/sprint. What that means is that if we have 5 team members, our team velocity will be 25 points a sprint. If you know some members will be out for a few days or there will be a holiday, make sure you account for that as well. Once we have decided on a velocity for that sprint, we commit it into Rally so that our charts have a number to refer to.

Product owner explains priority of the Backlog

It’s always nice to have the sprint priority explained prior to pulling in stories. Our Product Owner will discuss the theme of the sprint one more time and mention any critical or major defects that may have to be pulled in immediately. Once we understand the direction and priority of the sprint, we begin quickly adding or subtracting stories from the iteration story board until we have the agreed upon velocity.

Revisit each selected story

At this point, we will go through the selected stories and comment on any problems or dependencies that may exist with the upcoming stories (What blockers could come up? Are there skill set gaps?, etc). If my team has not already tasked out the story, we will go down our “definition of done” or import tasks from our task template and make sure that the story is fully fleshed out. We will then assign the tasks with estimated hours to the developers so that they can start accumulating work. We will complete this routine for each story until each of the stories is done. If we notice that a developer is over their capacity threshold, we will either push off the story, take on the extra work, or try to get help from another team. Hopefully by the end of the Sprint planning, each team member is at about 80-90% capacity, with work that fits their skill set. If for some reason, there is a lack of work (which there never is), we will find ways to utilize them by fixing bugs or have them pair program with another developer.

Finalize and Commit to the Sprint Plan

If your team has prepared well, the Sprint planning should be fluid and efficient. I love finishing the meeting with the agreed upon amount of story points, every developer with a comfortable amount of tasks, and the vision for the Sprint fully understood. Once everything is locked in place, we like to commit to the sprint so that we all agree on our responsibilities. It’s the last informal agreement that we have before we get to work. Once we have done that, we hit the ground running and start developing!