Sprint planning basics
Sprint planning is, simply, the time when a team plans its sprint; it happens on the first day of the sprint. Legacy Scrum tells us that we have up to eight hours to plan for a 30-day sprint. In the past five years, many teams have moved to two-week sprints, and sprints of one or three weeks are also common. In any case, when the sprint length is shorter than one month, it's logical that the team should reduce the amount of time spent in sprint planning. A two-week sprint, for example, should not require a team to spend more than four hours of sprint planning (and can usually be completed in just a couple of hours). I worked with a team a couple of years ago that planned its three-week sprints in 15 minutes. And they consistently completed 85 to 95 percent of their commitments. More planning doesn't necessarily mean better planning!
Weight Watchers is very similar to Scrum. When a person begins the Weight Watchers program, he/she initially weighs in so that there is a baseline for assessing improvement. The person identifies his/her target goal and works in weekly increments to lose weight and improve health. Weight Watchers is known for its weekly weigh-in, which is similar to a Scrum team's sprint review, and for its weekly meeting, in which dieters talk about how the previous week went for them and to plan for the upcoming week. Weigh-ins force visibility and accountability of results, and although a dieter may request a "No Weigh-in" pass, it's probably not productive to do so each week. If a dieter's progress isn't visible, it's impossible to know if he is making steps in the right direction, doing the right things; therefore, it's impossible to adapt. Without visibility there is no urgency. Weight Watchers encourages its members to attend the weekly meetings to learn from others, envision the week ahead, devise a strategy for the week, build excitement, and make a commitment. The spirit of a Scrum's sprint planning meeting should be exactly like this: envision, get excited, and commit. Unfortunately, this spirit gets crushed in the real world by mechanics—that is, agendas, rules, outputs, backlogs, and numbers that really are just a means to an end. As ScrumMaster, you should change the mechanics and tools as needed – heck, do away with them altogether sometimes! You'll be surprised to see how your meetings change when you focus on the feeling that you're trying to create, and not so much on the measurable stuff. Change it up; don't be afraid to experiment.
Over the past decade, many team members have told me that they loathe sprint planning; I consider this the ScrumMaster's fault. Your responsibility as ScrumMaster is to make this meeting a meaningful and interesting part of the team members' experience. If your idea of running a sprint planning meeting is to project a spreadsheet on the wall while developers sleep at the table, drooling from their mouths, stop it now. If you have created tasks for team members, stop it now! If you have suggested to team members how long their tasks should take, please stop it now! A ScrumMaster should create an engaging environment in which team members may contribute. During sprint planning, they should discuss important design and coding approaches, figure out test cases, and create their own sprint plan. Don't waste technical professionals' time by having them watch you type tasks into a spreadsheet or other tools during this meeting. Nor should they have their tasks dictated to them, or their estimates handed to them by you or a team lead. They are plenty capable of doing this stuff themselves.
And finally, by all means, the team should not be pressured to commit to seven stories when they feel that only three may be done competently. Sprint planning is intended to be an active, thoughtful discussion among team members to share a vision and plan for the sprint, ultimately so that they may arrive at a commitment that reflects a realistic, professional quality deliverable.
Note
Let's say that one day I have to see a doctor because I'm having heart trouble. After a few tests, the doctor calls me to his office, shuts the door, and has a very serious look on his face. "Stacia," he says, "you need open heart surgery. This surgery won't be easy because you have several complications. I'm thinking that you're going to be out for four or five hours; you'll wake up with a very long scar along your sternum, and it'll take you six to eight weeks to recover. And, by the way, this surgery isn't cheap. It's going to be in the $100k range." I have a blank stare on my face. I'm troubled as I imagine such a grisly and invasive surgery. I look up at the doctor and I say to him, "Doc, I respect you as a professional and all. But I need to be up and about within two days of surgery, I don't want a long scar. Oh, and I only have one thousand dollars to spend on this. Think you can help me out?" Of course, the doctor sends me on my way and slams the door behind me. The doctor would never agree to such terms; he's a professional and wants to do a quality job. Why, then, when pressured, does our software developer relent on her estimates? "Two weeks?!" her manager exclaims. "Why, you should be able to do that in two days!" And the developer looks at her manager, nods her head, and says, "Ok, two days it is." What do you think happens as a result of this compromise?
The clock officially starts ticking for a sprint during sprint planning when the product owner and the team get together to discuss what they will commit to for the sprint. During this meeting, the product owner explains the highest value items in the product backlog, and the team tells the product owner what they feel they can realistically commit to. Check out an excerpt from Agile Project Management with Scrum, Microsoft Press:
Sprint planning meetings cannot last longer than eight hours—that is, they are time-boxed to avoid too much hand-wringing about what is possible. The goal is to get to work, not to think about working.
Many ScrumMasters, I've found, mistranslate this eight-hour time box as, "I need to fill up an eight-hour meeting with all sorts of planning activities." No! Nothing could be further from the truth! It seems that the more time a team has to plan, the more anxious they can get about the work, so plan with a "just enough" mind-set, and then hop to it!
Just like the Scrum framework provides a light framework in which work will happen, think of your sprint planning agenda as a light framework in which team members interact. You have a well-constructed agenda if the team does the talking and is interactive 80 percent of the time, or more. If that doesn't describe your meetings, please read on.