So you have your product backlog chock-full of sprintable items. User stories, dev chores, a few bugs—all estimated, of course, right?!? Your team is ready to rock, so where do we start?
We start with my favorite scrum thing: the Sprint Planning Meeting.
Now, my appreciation for this piece of an agile team’s process stems completely from a systems perspective. Hopefully, attending the meeting itself is not exciting or full of surprises. But I still love it because, when done right, it serves as a well-tuned constraint to which all other agile or scrum things can be subordinated. This keeps the team sustainably and happily delivering regular measurable progress.
Here are my guidelines for a successful Sprint Planning Meeting:
Invite the Right People
Only invite the product dev team and product owner. Another way to think of this is that you should only invite people whose daily work is driven by the product backlog. This could optionally include designers and testers.
Do not invite stakeholders, clients, end users, or domain experts. These people are important. We love them, and their perspective, input, and alignment are 100% required for a successful product. But we should have gathered everything we need from them before the Sprint Planning meeting. Explicitly leaving them off the calendar invite will force you to bring decisions and consensus to the meeting instead of allowing it to devolve into a hybrid planning and backlog grooming session.
Bring Sprintable Work
Ensure the top-priority items in your backlog consist of, at least, two to three sprints worth of sprintable work based on your team’s velocity. A story is considered sprintable if the dev team believes they have all the information needed to fully deliver it without taking more time to ask questions outside of the dev team. (There may be decisions to be made, but they should all be owned by the dev team.).
Having two to three sprints of sprintable work should give you more than enough to fill any single sprint—and give your team enough buffer to handle a temporarily absent product owner or a lull in backlog grooming progress.
Don’t Force a Commitment
The goal of a Sprint Planning meeting is to develop a plan for the team to focus on delivering over the next two weeks. You can call the plan a goal or the goal a plan, but it should not be called a commitment.
Forcing an artificial deadline every two weeks often results in sacrificing time a team should set aside to keep the product code base, test suite, and architecture in good order. Regularly addressing technical debt is important, and a team’s ability to precisely estimate what it can get done in two weeks shouldn’t decide whether or not it actually gets done.
Embrace Today’s Reality over Yesterday’s Estimate
Whenever possible, avoid using “yesterday’s weather” (the number of points completed last sprint) to determine how many stories to bring into your sprint. Instead, have your team assign each story a time estimate as you bring it into the sprint, allotting days or half-days to the story.
By estimating in time, you can accomplish two amazing things:
- You can get your team to truly evaluate what it will take to implement a story in the present context. The present context is always different in some ways from the context when the last points-based estimate was assigned. Your architecture and code base may have evolved (or not) in ways your team hadn’t anticipated. If it’s going to be easier or more difficult to implement a story, it’s important to ensure that everyone can be honest, get aligned with reality, and accept and embrace it.
- You can combine other time-based commitments during the sprint with the time to complete backlog items. Say you have one pair of developers and a two-week sprint. That’s a total of 10 pair days. Take away half a day for Sprint Planning and Sprint Review, another quarter-day for Backlog Grooming (because we need to estimate some stories), and three quarters of a day for a previously planned trip to meet with our client onsite. We now have 8.5 remaining pair days. Oops, we also have a holiday during this sprint—Memorial Day! Now we’re down to 7.5 days. The team has been reserving half a day to address technical debt issues and invest in architectural improvements each sprint, so that makes 7.0 pair days for sprintable work. Now, we can adapt to the current sprint’s reality when loading it with user stories.
Using a constrained approach to sprint planning can be the keystone of a great team process. And what’s the result? An adaptable and happy team.