The Sprint Planning Meeting

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

Basics

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.

Stories

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.

Tasks

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.

Commitment

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 » »