How to Make Sprint Planning Suck Less

When the term Sprint Planning comes up, it’s usually met with groans from developers. “There goes my day,” I’ve heard said — probably by myself at some point. But it doesn’t have to suck. I’ve seen a few approaches to sprint planning, and I’m going to lay out what has worked for me and my team, and what hasn’t.

While at Clarity Hub and my previous job, we’ve used agile methodologies and sprint planning to organize and manage our development work. But while sprint planning goes smoothly at Clarity Hub, there were quite a few hiccups at my previous employment that made sprint planning drag on.

Focus on Results

Don’t worry about nailing down the sprint planning process. The goal of sprint planning should be to set the team up for success. Craft a sprint goal, create a sprint backlog, and get the team ready to execute the sprint. At the end of the sprint, hold a retrospective and discover what went well, what didn’t go well, and how the team can improve.

This is how you will go about nailing down the sprint planning process. Listen to your team, iterate on your process, and try again. When the team lists ways the sprint and sprint planning process can be improved, takes steps towards actually implementing those changes.

I’ve seen sprint planning sessions devolve into discussions of poker planning versus story points, or t-shirt sizes versus fibonacci numbers. Leave those discussions for the retrospective, and instead focus on creating the sprint goal and sprint backlog with the tools you’ve picked.

Groom Your Backlog

One sure-fire way to make sure your sprint planning session goes smoothly is to make sure your backlog is up to date before the sprint planning session. There’s exists no better way to ensure a long, drawn-out sprint planning session then to have to add a bunch of new tickets to the backlog, prioritize the backlog on the spot, and figure out user stories for the top tickets.

Everyone should groom the backlog to some degree. Developers should periodically go through the issue tracker and clean up tags, ask for clarification on vague user stories, add bugs that they find, and help break up epics. The product owner should prioritize tickets to match what the business wants and should fill in the user stories for the top tickets as well. If you don’t have a dedicated product owner, the team should get clarification from stakeholders to the best of their abilities.

I’ve found that tracking everything helps: epics, feature requests, enhancements, bugs, and technical debt. Not only is it easy to forget a cool idea for a feature that you had, it’s even harder to know if someone else had the same idea if it’s not tracked.

Set Your Sprint Goal

While your team is sprint planning, setting the goals for the sprint is important. The product owner should come to the planning sessions ready with the top priorities for the team. If the team can get X number of tickets done, the product owner should have all the user stories for two times that amount.

The team negotiates with the product owner over the top priorities and determines which tickets are feasible, which need more information, and any technical debt the team may have to deal with.

In the end, the team will pick the highest priority items that the product owner and the business want done. These will be the goal the sprint. As mentioned before, the goal of sprint planning is to focus on results. Your sprint goal is the main result that should come from talking with your product owner.

Create Your Sprint Backlog

Now that the team has a sprint goal, and those goals have been elaborated on by the product owner, the development team can focus on how to implement the sprint goals.

The development team collaboratively makes sure that they have enough information to complete a ticket — which systems will be effected, what will the UI look like, and so on. If a team member doesn’t know how a ticket impacts the system, they aren’t going to be able to accurately estimate the cost of the ticket.

Tickets should also have clear requirements and a clear definition of done. A developer, product owner, or QA engineer should be able to look at a ticket at this point and know how the item should behave from its user stories. If your ticket says, “Improve the code for billing” — that’s not a very good ticket. But if it instead says, “Add tests for billing so that we reach 60% code coverage in that domain,” — there is a clear pass/fail for the ticket.

Executing

Making sprint planning suck less depends on letting your team help improve the process, work together, and have autonomy in how the implement their tickets. Sprint planning isn’t about the tools you use, but rather the results you get from planning.

Pick the tools that help your team. Our team at Clarity hub arbitrarily assigns numbers 1 to 10 to a ticket. We tried Fibonacci, T-shirt sizes, etc, but in the end, we just stuck with a simple 1 to 10 scale. The team found that it was just easier to use gut feelings for tickets after listing all the work that needed to go into a ticket and identifying any unknowns in the ticket.

We also have a loose definition of what counts as an “epic”: if a ticket is over 4 points, that usually means it needs to be broken up into smaller tickets.

The points and scaling will vary from team to team, but as long as everyone agrees and starts getting a hang of it, the points will help you track your team’s velocity. Even though the points are arbitrary, they help track a ticket’s sense of scale.

As long as everyone on the team is held accountable for their points, it doesn’t matter if you use planning poker, story points, or some other convoluted way of determining ticket points. The focus should be on using your sprint planning time to set a goal, create a sprint backlog, and execute on it.

Ivan Montiel is the founder and CEO of Clarity Hub — a company that integrates with Intercom to give customer success teams real-time suggestions.