Let’s get meta for a minute.
When it comes to planning, what’s your team’s plan?
Meetings generally drag on too long and they tend to ignore or leave unanswered all of the important questions that you’ll then have to have another meeting to discuss later.
Ideally, we could skip all that.
If your team runs a tight ship, you can run quick and efficient sprint planning meetings. You can eliminate confusion and questions. And you can plan your sprint in a more accurate and predictable way.
Here’s a step-by-step guide on running better sprint planning meetings.
State the Goal
Any agile practitioner knows that the most critical component of kicking off each new iteration is to pin down a specific goal that the team hopes to accomplish over the coming week(s).
The stated goal shouldn’t be technical and detailed. We want to begin with a high-level objective that we want to accomplish, and then explore the specifics of what that means in terms of actual work.
There could be multiple goals for the sprint, such as:
1. Test and launch new time tracking engine
Develop a team reporting feature that is ready for testing
Goals for the sprint usually come from the Product Owner and then are given to the team as a way to begin the conversation about the specific scope of work to be completed.
Keep in mind that a goal is just that–it’s a goal. It’s what the team would like or hopes to accomplish. But it shouldn’t be dictated as a certainty. If the rest of the planning process reveals that the goal is unrealistic, then it should be adjusted as necessary.
2. Confirm the Capacity
Goals are great. But can your team get it done?
The team’s capacity is often in flux. Although we may assume that the team remains relatively static, calendar items like meetings, vacations, and holidays can change the amount of work that is realistic to complete in the given time period.
The capacity, goal, and scope are the three main conditions that must be balanced in order for a sprint to be successful.
An overambitious goal may force a team to exceed their capacity. And, likewise, a diminished capacity can make it impossible to achieve the full scope for that iteration. The main goal of the sprint planning meeting should be to resolve these to create a sprint plan that is both achievable and efficient.
3. Scope the Work
The third component of any sprint plan is the specific scope of work. This comprises all of the user stories and individual tasks or product backlog items that need to be completed in order to satisfy the stated goal.
In other words, this is the stuff that the developers will actually get done.
For most teams, this is a matter of pulling things out of the backlog based on the stated sprint goal and priority, then piecing them together to fill the available capacity.
If things are well organized, this shouldn’t be a monumental task.
The key thing to remember–and where there is sometimes a disconnect in this process–is that the team must ultimately decide and agree on how much work they can complete within that sprint or iteration.
It can be tempting for the Scrum Master or Product Owner to look at a roadmap and try to drive this conversation (e.g., “we need to have this new feature done within the next 2 sprints, so we need to include half of the work now.”) But this is backward and will lead to failed sprints.
Instead, each backlog item or user story should be discussed and scoped into specific tasks that can be assigned story points, effort, and/or time estimates.
Again, we see that the point of the sprint planning meeting should be to balance the goal, scope, and capacity.
If there simply isn’t enough time or capacity to complete all of the tasks that would lead to a successful sprint, then there needs to be a negotiation about the stated goal.
4. Do a Sanity Check
One of the major pitfalls that leads to failed sprints is the use of intuition.
To put it in scientific terms, teams tend to rely on what Daniel Kahneman dubbed “System 1” thinking rather than “System 2” thinking. In other words, teams look at the scope of work, the specific tasks, and the goal, and they go with their gut–either they can do it or they can’t.
But there’s a big problem.
System 1 thinking is inherently flawed. It’s prone to logical errors and overestimation. This leads to what’s commonly known as The Planning Fallacy. We tend to bite off more than we can chew.
We’ve written previously about why time and work estimates often don’t match reality.
This is where those issues are born.
Everyone is excited and confident at the beginning of an iteration and they set ambitious goals for what they can accomplish. But they never bother with considering any empirical data on whether that is a reasonable amount of work.
In addition to helping developers gauge their own abilities, this is where time tracking can be an extremely valuable tool to root estimates in some level of real-world data.
It may tempting to trust your instincts on how long certain tasks might take or how difficult they will be. But, at the end of the day, this is just guessing. And it leads to failed sprints.
Instead, do a sanity check. Take the time to analyze your past performance as an individual developer and as a team. Compare the upcoming work to similar types of projects in the past and evaluate how closely your current estimates line up with past reality.
This step will save a ton of headache and frustration later down the line.
Get the Hell Out of There
Developers pretty much universally agree that meetings suck.
They often take too long and accomplish too little.
The goal of any sprint planning meeting should be to minimize the amount of time that it takes to relay and agree on the necessary information. That’s it. No more, no less.
If the team is able to do this and can find a quick rhythm where everyone understands and anticipates what part they need to play in the planning process, then it becomes second nature. The team can get in, get out, and get back to work.
Sprint planning doesn’t need to be difficult–nor time consuming.
But, the team should also resist the temptation to cut the meeting short just for the sake of expediency. This is a critical part of any software development cycle and it sets the pace and expectation for the coming weeks. It’s worth spending a little extra time to make sure you get it right.
With the right plan and the right approach, you can have better, smarter, and quicker sprint planning meetings without setting the team up for failure.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.
Top comments (0)