Tips For Running A Sprint Planning Meeting

Build better software, more quickly, with less risk

For the past 2 years or so, we’ve been using an Agile-ish methodology for the development of our marketing automation platform.

I’ve described how we use daily stand-ups (here’s a real-life video example) during development of our MVP (minimally viable product), and today I’ll share how we run our Sprint Planning Meetings.

Here are a few things about Sprint Planning that we’ve found to be uber-helpful:

1.  Holding the meeting every 2 weeks on Friday seems about right for us. We used to have the session every 3 weeks, but for some reason, having a week in the middle caused us to get a little loose. For us, a 2 week Sprint gives us 9.5 days of work, and its enough time to make significant process, but not enough time that we get fuzzy in our estimates.

2. On the day of the Sprint Planning Meeting, we don’t have a Scrum Meeting. Instead, we use the time to address any last-minute issues, as well as prepare for the Sprint Review. It is helpful to ask everyone to use this time to prepare for the portion of the meeting where their work is displayed, so that everyone’s time is maximized during the meeting.

3. During the Sprint Planning Meeting, we use a three-part agenda, as follows:

• Sprint Review, during which we review all the completed User Stories. Reading from our status whiteboard, we work our way through each User Story.  The person responsible for the User Story does a brief demo, articulating the main points of what has been accomplished.  This is this is a very exciting time, and gives everyone an opportunity to see, hear, and learn about what everyone else has done.  After each person finishes, we all applaud!  Hooray!

• Sprint Retrospective, during which we talk about the prior Sprint and the processes we used. We look at two things: what went right, and what we can improve. We solicit everyone’s input, discuss their thoughts, and document everything. If something requires an action, we try to arrive at a specific next step (but to be fair, this is something we can improve).

• Sprint Kick-off, during which we review the User Stories for the upcoming Sprint. We’ll go through each User Story, talk about who is involved and what they need to do what to accomplish the User Story, and get a rough estimate of the effort required by each person. While we do this, we also enter the User Story and each Task into TFS (Team Foundation Server).

4. We previously used an entire day for the meeting, but now seem to only require 3-4 hours. We start our meetings at 1:30 PM and are usually wrapping up by 4:30.  This seems to be around the right amount of time, as things are never rushed, but we move at a good clip.

Using this process has given us a predictable rhythm to work from, and the fact that the meeting is every two weeks give us a great way to time-block our activities.  We feel it is helping us build better software, provide better value for our Clients, and we’re moving much more quickly than we ever have in the past.

What about you? Do you run your Sprint Planning Meetings in a similar way? What best-practices have you found?