Sprint planning meeting: getting agreement before executing
Sprint planning isn't just about breaking down tasks, but getting everyone to row towards the same objective.
Previously, in the “The art of running a backlog refinement session (i.e., grooming)”. I wrote:
The sprint planning session results in a commitment by the product team to specific work during the sprint …
For most product managers, the concept of working in 1, 2, or 3 week sprints and running a sprint planning meeting is almost second nature. But are there techniques to get more out of your sprint planning meetings?
Reflecting on why you have Sprints
Before diving into sprint planning meeting tactics, it’s important to assess how you/your product team uses a sprint. I believe there are three categories.
A. Sprint as Monitor: Under this mode, the sprint is used to break up a larger project into smaller, time-bound increments to monitor if the product team is hitting anticipated milestones. The overall project has set a fixed launch/release date. Prior to this date, there will not be any releases to users. If there are releases, it’s to test functional or usability, not value. As a result, any release for testing is usually close to the anticipated release date. During a sprint, any unfinished work that’s included in a sprint automatically rolls into the next sprint. This mode uses sprint ultimately for monitoring and control.
B. Sprint as Structure: In this mode, there is no set launch/release date. Instead, the product team is presented with business objectives and measurable target metrics. The target metrics are within the product team’s control/influence. The product team works toward a single goal across several sprints, but how many sprints are determined solely by the product team. Unfinished work may roll into the next sprint only if there’s value in helping the team reach it’s business objective. This mode uses sprints primarily to structure work.
C. Sprint as Agility: In this mode, the product team uses a sprint to quickly respond to drastically changing feedback. Each sprint, the team may work on entirely different product/features by releasing something to test value. All unfinished work is dropped between sprints. This mode uses sprint to enable quick reaction to changes, providing improved flexibility to test in smaller increments.
It’s likely that your sprint exhibits some characteristics in all three categories. However, if you reflect over the last 3 - 4 months, you should discover that your sprint likely falls under one category more than another. The above simplified categorization provides an easy approximation of how you should adjust your thinking when running spring planning meetings.
This is because most content around sprint planning focuses on optimizing for those in C. Yet, I think more product teams operate in A or B.
How to run a good sprint planning meeting
Acknowledge how you’re using sprints. You can’t adjust your sprint planning if you don’t know how you are using sprints.
Adjust your sprint duration appropriately. While it’s common practice to see 2 week sprints as the norm, a sprint duration depends upon your release cadence. Often, I see sprint periods that are shorter than the release window. Thus, completed features/code sit too long and require rework again before release. Furthermore, issues during the release process may cause members of the team to drop what they are currently working to recall the code/feature they previously worked upon. This creates unnecessary task-switching, increasing inefficiencies.
Set aside a recurring time. Typically, it’s recommended to hold just before or when your new sprint starts. Keep it to an hour. However, if you are running sprints more to “Monitor”, where unfinished work automatically rolls into the next sprint, it’s better to shorten sprint planning meetings. Instead, use standups and retrospectives to identify impediments to completing working during a sprint. On the other hand, if the sprint is longer than 3 weeks, set for 1.5 hours max.
Write down a single, sprint objective. Most people start sprint meetings by directly diving into detailed tasks: user stories, spikes, bugs, etc. But it’s often better to define a single objective the team seeks to accomplish. When you set this objective, you’ll quickly discover if it’s achievable for a single sprint or over several sprints based on feedback from other members. This is another indication of how you’re using sprints.
Regardless, writing down an objective forces individuals on the team to prioritize. If you have trouble landing upon a single objective, it can signal other problems (e.g., too many objectives, not enough focus; issues with team dynamics, unclear objectives). Unless your product teams are large, single objectives make most sense for teams with less 5 - 6 individuals.
Define your product team capacity. What’s often forgotten during sprint planning is acknowledging the team’s capacity. This is where accurately tracking story points can help you create a baseline. Even if you don’t have a baseline, you should make up one after taking into account vacations and general velocity. All too often, sprint planning meetings end with a committed set of stories and objectives that’s above the capacity of the product team. Thus, the team is set up to fail or carry over unfinished work. I try to measure carry over work to be less than 10% of committed story points. However, it’s not unusual to see carry over work to be 50%+ of committed story points. While I like ambitious teams, consistently overestimating capacity will overwork and demoralize a product team.
Discuss stories and/or break down tasks. This is the one most people focus upon. The marker I use to determine if a task has enough details are:
a) Do we know how to articulate “done”?
b) Can software engineers provide story point estimation?
c) Could any software engineer on the team pick up the story and know what to do first?
The marker for “done” will thus vary based on the skill, maturity, and knowledge of the software engineers within a product team.
Additional Reading: