Agile Software Planning: What to do if Classic 2-Week Sprint Planning isn’t Working for Your Team

The Problem

On August first, I left the team I’d been working with for over three years, and became the product manager of a nearby team called Catalyst. Catalyst was a very high performing team; it had ten engineers, eight of which were “Sr. Engineers.” Catalyst was a heavy hitter team.

During a retro two and a half weeks after I joined, someone brought up the issue of our planning sessions. They weren’t working; the whole team agreed. The chief complaints were:

• Our planning sessions were really long. We all spent an hour in a zoom call every Monday (technically these were alternating “planning” and “refinement” sessions as part of a “2 week sprint”). They were long, not the most engaging, and questionably productive.
• Most of our tickets didn’t have context; it wasn’t clear how they connected to a bigger goal.
• We didn’t have nearly enough small group scoping/planning time. People were craving whiteboardy, 3–5 person sessions where we could really break things down and design/architect solutions.

This topic ended up eating up more than half of our retro. It was clear the team was very unhappy with its planning rituals. We realized we weren’t going to solve it right then. Instead, the group deputized three of us to craft a proposal to bring back to the group.

What We Tried

Later, the three of us in the proposal committee got together and reviewed the problems. We discussed the very real burden of planning/meetings fatigue that can set in for an engineer, and sap their productivity for an entire day (or more).

In line with Agile first principles, we tried to take a step back and ask why we were doing planning meetings. Why were we doing two week sprints? Why were we separating planning and refinement? What problems were the most important for us to solve with our planning rituals? Were we just doing it because most other teams do it this way? What was the simplest thing we could try to address our pain points and embody our values?

We wrote out some statements we wanted to be true about our new system:

• We don’t want to be tied to two weeks. We want a system that expands and shrinks week to week based on how much planning the team actually needs to do that week.
• We saw no useful distinction between planning and refinement.
• We wanted individuals to be able to opt in or out of planning based on their own personal needs, interests, or time constraints.
• We wanted to drastically reduce the amount of time all 12 of us were on a call staring at our Trello board. We believed that this was exhausting for the team, and not very productive. There were too many people in the room to do the real hands-on planning we were craving.
• We wanted to optimize for 3–5 person working sessions where we could actually scope tests and solutions and write tickets.

After some no-bad-ideas brainstorming and subsequent spitballing, this is what we came up with:

• Every Monday is the same. No difference between “planning” Mondays and “refinement” Mondays.
• At 10:30am every Monday, we all join the 30 min “Opening Ceremonies” meeting.
• We have four other 30-minute blocks of time scheduled every Monday throughout the day: Block A, Block B, Block C, and Block D.
• At Opening Ceremonies, the PM and Engineering Manager present the latest regarding the larger product & delivery context. Anyone leading a given test or product gives a brief update. Someone gives a tech health update.
• The group then decides how best to use the four usable blocks that day. Which projects need planning time?
• The groups decide when “Closing Ceremonies” are; either during one of the Usable Blocks, or at Standup on Tuesday (if we run out of blocks). Everyone shares updates in Slack and in a common planning doc.
• Projects can use Blocks as small group planning time. Small groups talk project goals, break down tasks into sub tasks, and write tickets together.
• Closing Ceremonies takes just 10–15 minutes. Each small group updates the team on what they did.
• At Closing Ceremonies, the team reviews any upcoming deadlines that will inform ticket by ticket prioritization.
• What are we working towards? We review tests etc we’re working towards

We named it Olympic Style Planning because we had taken to using the phrases “opening ceremonies” and “closing ceremonies.” (Plus, everyone knows a cool name is a crucial part of any new plan!)

Schedule for a typical Monday in Olympic Planning

What We Liked About This Idea

There were a few things we were particularly excited about regarding this new idea.

• The process was completely elastic; some weeks when we had a lot of planning work to do, we’d have 2.5 hours of planning time already blocked off on the calendar. Other weeks, when we had lots already scoped out, we could have a 15-minute check-in at Opening Ceremonies and then be done. Engineers could get right to work.
• We drastically cut down on big meetings, and optimized for 3–5 person working sessions.
• We empowered our future selves to decide what needed planning. A block of time could be used for blue-sky ideation, scoping out a test, or talking about tech debt.

Did It Work?

Catalyst tried Olympic Style Planning for 3 weeks, and then did another retro to reflect on what was and wasn’t working. Did we want to keep Olympic Planning?

The feedback was overwhelmingly positive. For all the reasons we’d theorized, the team liked Olympic Style Planning far more than what we were doing before.

The biggest problems people were having with it were:

1. If a person missed a planning session for a product they were interested in, they felt completely lost afterward and didn’t know how to plug back in. We realized we weren’t really doing “Closing Ceremonies,” and it was really hard for engineers to catch up on planning sessions that they missed.
2. If a person was interested in everything we were doing, it made for either tough choices or a very long Monday of meetings.
3. If we weren’t super exact about doing meetings at the right times and with the right dial-in links, people had a very hard time finding a planning session.

We focused on problem #1 above. Number 2 felt too hard to fix, and #3 was easy enough to fix with a recommitment to being exact on times and links.

To solve for #1, we abandoned the concept of Closing Ceremonies. Instead, we decided to keep a running “Olympic Planning” doc where we kept track every week of which Blocks were to be used for which topics. We instituted a new rule that said that:

• Every Block is accountable for adding to our planning doc what was talked about and adding a link to any and all tickets, scoping docs, etc that were updated as a part of the planning session.

We realized we didn’t need a synchronous closing ceremonies; what we needed was a way for individuals to catch up asynchronously afterward.

Lessons Learned

Overall, Catalyst views Olympic Style Planning as a huge success. An elastic process that optimizes for working-session style planning is exactly what Catalyst needs right now.

Someone asked in our recent retro: “Should we reinvent more of our weekly rituals in this same way?”

We talked briefly about our current processes for Standup and Retro, and decided there were no burning pain points with either just now. So we decided not to reinvent those processes.

I am most excited about the way in which we enacted the values of the agile manifesto without getting too wrapped around the axel with the common practices that have gotten conflated with the concept of agile development itself.

Once upon a time, a team invented 2-week sprints (with planning and refinement) as a process which met their needs and solved their problems. Unfortunately, I think too many teams adopt this kind of process under the guise of agile without actually asking hard questions about what their pain points are and what outcomes they’d like to achieve through planning.

If it sounds interesting to you, I’d encourage any team that doesn’t like their planning rituals to try Olympic Style Planning; but that’s not really the point. The real point is this: we should all be continuously reflecting on our processes and asking ourselves, “is this working for us?”

The genius of Agile is not in its rote processes. It’s that it encourages us to try big bold things quickly, knowing that nothing terrible will happen so long as your can quickly reflect on whether or not that thing is working (and change it/change it back just as quickly if need be). Fast iteration informed by fast feedback loops. Drastic change is only scary if you can’t alter it/change it back quickly.

We’re still doing Olympic Style Planning! It will continue to be our favorite way of doing planning until it isn’t.