The Sprint Planning Meeting

Note: This is one in a continuing series re Scrum Intro.  The preceding related post is here.


Before the Sprint Planning Meeting (SPM), there must exist a Product Backlog with small Product Backlog Items (PBIs) at the top of the list. The PBIs must be estimated. Specifically, we recommend User Stories and estimating using Story Points.

We recommend that the Business Stakeholders and the whole Scrum Team attend. You may allow others to attend, but be careful.  For a two-week Sprint, the maximum length is four hours. I divide the meeting into two parts.

This is what I call a “drama-in-real-life”.  One of the purposes is that we are enacting our commitment together, in the face of the whole company.


The first part I call stories. In that short part we review and agree on the stories in the Sprint. Everyone together. Everyone can see all the information we have on each story, ask questions and add or clarify information.

While we hope this would have happened before, the Implementers can reject any story they think is inadequate (we do not have sufficient information to do it professionally).

As each story is discussed (briefly), in some way the PO says to BSHs (one or more): “Speak now or forever hold your peace.” That is, any BSH must say now any detail that he or she might complain about later. Any change or addition of information.  If they are unhappy in the Sprint Review, it is likely because they did not speak up now.

Similarly, the Implementers get to decide how many stories can be brought in this Sprint. The typical main factor is that if the average velocity is 20, they are not likely to bring in more than 20 Story Points of stories without some good reason (such as that an impediment has been fixed and we expect the velocity to start to be higher).

It is the Doers who get to pull each story into the Sprint, one story at a time.  And the Doers can say “no more”, for any reasonable reason.  They must not over-commit, nor should they under-commit.  (Almost always over-committing is the bigger problem.)

It is important that all the top stories are small and about the same size, and we recommend that a typical Sprint for a team of seven has about eight stories. With a velocity of 20, that means a typical story would be two or three Story Points in size.

This first part has usually been planned before, and this is a final review. So, typically this is done in 45 minutes or less. The BSHs can leave after the first part is complete. We want this part short and sweet, so the BSHs will attend.  They do not need to watch us do story pointing, for example.  If that were the case, the BSHs will probably not attend.


The second part we call tasks. This will take longer — often most of the remaining time, as much as three hours or so. Once teams get experience, this starts to shorted. Often the whole Sprint Planning Meeting (for a two-week Sprint) can be done in a total of three hours.

“Well begun is half done.” But also remember: “Everyone has a plan until they get punched in the mouth.” (Mike Tyson)

By task we mean a set of work, so that when we do a few of them together, the tasks complete a story. The story has Business Value (at least in the eye of the PO), but a task by itself does not deliver Business Value. Or, another way: We can demo a story and get feedback. It is not normally useful to demo a task.

Each person creates his own tasks, although people can work together. Each task should typically take two hours. Maybe a few are as short as one hour. A few can be longer.  Rarely a couple maybe as long as six hours. The key thing is that the short task allows each person and the other members of the team to feel some completion, some traction each day by each person.

The small tasks also force people to admit to impediments in the daily stand-up. Sometimes the only real impediment is that I am bad at estimating, but even that is a learning experience, and we all become better at estimating the tasks.

“If you want to change the world, start by making your bed.”  (Adm McRaven)

“One small task done leads to another small task done.”

All the new teams at first are usually very bad at creating the small tasks, but as Goethe said, “Everything is impossible until it becomes easy.” That is, when we don’t know how to do it, it is impossible for us. As we learn and practice and practice, it becomes easy.

So, each task is described, assigned (or volunteered for) and estimated. After the individuals have created “all” the tasks, we allow everyone on the team to see the whole Sprint Backlog (the stories and their tasks), and anyone can ask to change it, describe an item better, re-assign tasks (in fact that can be done at any time during the Sprint), re-estimate a task, and add or eliminate tasks.


When the Sprint Backlog has been improved, the team can now commit. I prefer to do this with fist to five voting by each Implementer. A fist is zero: no confidence. Five fingers is maximum confidence that they can get all eight stories fully completed in this two-week Sprint. We want all the Implementers to have three or more fingers.

If not, then either the Sprint Backlog needs to be discussed or improved, or the number of stories reduced (or possibly increased if they feel that is reasonable).

Commit does not mean guarantee. With normal (good) stress, about 40 hours per week, with faster response to questions, and a SM dedicated to fixing impediments, the team should soon become 70 percent to 80 percent reliable in meeting their commitments. Reliable for one sprint means all the stories committed (or more) are done-done at the end of the Sprint (as per the DOD). So, 70-80% reliable means that for seven or eight Sprints out of 10, they get all the stories (or perhaps all the Story Points) that they’re committed done-done. Or more.

If they fulfilled their commitment in 100 percent of the Sprints, that would be too high, and below 50 percent is actually more unreliable than reliable. A lot of good disciplines occur when they learn to promise what they usually can complete. As one example, it forces them to minimize WIP, at least to some degree. It forces them to learn to estimate decently. It forces them to insist on at least some details before the story comes into the Sprint. They become more serious about fixing impediments, etc., etc.

Note: The next post in this series is here.


« « The Sprint and the Meetings || The Daily Scrum » »


4 thoughts on “The Sprint Planning Meeting

  1. Pingback: The Daily Scrum - Lean Agile Training

  2. Renee

    Using Scrum poker at this point is helpful. Using Scrum poker, you can quickly initiate sprint planning meeting, estimate man-hour more accurately by voting, and save time on coordinating. Team members gather together and choose cards to represent the number of man-hour they estimate for the task. By placing cards face-down to the table, it minimizes the influence on others by speaking that out.

    Scrum poker, AKA planning poker, is a concensus-based tool for estimating and planning effort/man-hour in software development projects, especially in Agile development, such as Scrum and Extreme Programming. It was first designed by James Grenning and became popular in Agile Estimating and Planning written by Mike Cohn who made Planning Poker a trade mark and an online tool.

    Project Management software tycoons, such as JIRA, has its own scrum poker add-on. You can integrate it, if you use Jira.

    If you prefer a physical poker, you can try ZenTao poker. ZenTao is open source project management tool designed by an Agile team and for Agile teams. It is an All Lifecycle Management, covering the whole process of software development. What distinguishes it from other project management tools is that ZenTao divides the complex project management process into four major items: story, task, bug, and case, through which ZenTao supports the whole flow of management.

    1. Joe Little Post author

      Hi Renee,
      You raise several issues.
      First, let me strongly advocate for Story Points and to not estimate in hours or days.
      Second. I strongly agree that we not not want one person dominating the conversation. And averaging with the Fibonacci cards is one way to do that. But it often needs a faciltator and explainer to keep bad behaviors away.
      Third. Consensus-based? Well, the right way to to get them close (within 3 consecutive Fibonacci cards (3-5-8 as an example) and then average their opinions. When some people use the word “consensus” they mean that all the Implementers must agree on only 1 Fibonacci number. That is actually not the correct method per those who have studied this approach a lot (eg, Rand Corp). But I agree with you that averaging is a kind of consensus.
      Fourth. Glad you mentioned James Greening and his article. I will add that reference.
      Fifth. You mention a number of tools to support Fibonacci voting (averaging). Indeed there are many. Better to do it co-located with the cards. But, my ideal would be using smartphone apps, and then someone can press a button, and the “back-end” averages automatically. I have not seen (yet) and app that does that. But I have not checked out every smartphone app.
      Sixth. Per the first line of the Agile Manifesto, I am not a big advocate of any tool. Tools mis-direct the mind. What is important is the people, not the tool. Further, Tasks -> Stories -> Releases is not a bad conceptual idea. Adding bugs and cases in there muddies things. Not sure I am happy. I guess I must discuss “bugs” soon.

      Thanks for your comments!
      Regards, Joe

Leave a Reply