No battle plan ever survives contact with the enemy

In a continued push for asynchronous work, we attempted to tackle one of the last major meetings we had — Sprint Planning. I’ve found this to be the most dreaded meeting for developers since it’s often a time sink.

With a 2-week-long sprint, traditional scrum calls for a 4-hour meeting to set a goal and plan which issues will be released at the end of the sprint. The team should also determine how to achieve this. Planning is done with the entire team present so it becomes rather expensive.

In our attempt at async planning, the PMs created a Notion table with rows for each sprint. Inside the sprint document, we listed the epics that we wanted to achieve. We would write down the details for the epic so that the context was clear for developers. When a sprint started, we created the documentation for the following sprint so that developers had time to read, understand, and ask questions as needed. They could comment directly in the document, make notes about implementation approaches, and take time to think about potential pitfalls. Once everyone was on the same page, a developer would generate a list of user stories.

There are 3 things a PM should focus on: creating context, setting priorities, and eliminating distractions.

We still met as a team, using Zoom to have a face-to-face call, but now our meeting was 30 minutes long. As a team, we would discuss any last-minute questions, validate the task list, and make any needed updates. Overall, we succeeded! Our meeting was super short, morale improved, and everything shipped on time! Except that’s not what happened.

I really think this system could work given more practice, but we definitely ran into issues: planning is a distraction, sprint scopes change, and next week is next week.

Planning is a distraction

There are 3 things a PM should focus on: creating context, setting priorities, and eliminating distractions. Planning is a distraction. During a sprint, engineers should be focused on that sprint, not what is coming up next. I’m not saying that future work doesn’t impact current work, but it shouldn’t be the primary focus.

We found that sometimes we were getting ahead of ourselves, trying to plan out things to build on top of features that weren’t quite finished. Additionally, because the process was async, it needed to be started earlier in our 2-week-long sprint. If the team waited until the last minute, the planning wouldn’t get done and we’d be back to a 4-hour-long meeting. The solution here is one where sprints are less rigid. Unfortunately, there was a contractual obligation to use sprints on this particular project.

Sprint scopes change

Most teams that practice agile aren’t very agile, so this might not apply to you, but generally, you don’t want to decide what to build until it’s time to build it. PMs are constantly updating and reprioritizing the backlog. We had a couple of cases where we would complete async planning and be ready for the next sprint only for the goal and priorities to change.

Also, we had to handle failed sprints. Sometimes work would bleed over to the next sprint and we couldn’t know the volume of that work until the end of the sprint. How can you prepare your next sprint goal unless you know where you stand? The solution here is to work in smaller chunks. Focus on one problem and solve that problem as a team.

Next week is next week

The final issue we had is one involving personal organization. The real deadline for finishing the planning was just before the planning meeting. There was usually one team member who would do the bulk of the analysis early in the week. They would then remind their colleagues to check the document. If engineers kept focusing on code (as they should), they wouldn’t add their voice to the conversation. At the planning meeting, we discovered there was still more discussion to be had and the purpose of async planning was defeated.

The solution here is a bit tricky since it involves some interpersonal skills. Encourage team members to contribute and use positive reinforcement when they do. Having a structured unplanned feedback system that supports positive interactions is incredibly useful in this regard.

Don’t give up!

As I mentioned earlier, I think this system could work given more practice. Overall, we definitely did save time. Meetings are incredibly expensive and we still saved time even in situations where only one person looked at the async planning docs. We’ll definitely give it a try again in the future.

Don’t be afraid to play around with core scrum processes. You can make small experiments, learn from them, and constantly improve. Be wary of changing too much at once, but if you have a truly agile team, the engineers will want to test out new things just as much as you. Listen to their pain points and think about what you can do to better create context, set priorities, and eliminate distractions.

Interested in finding out which tools we use for working remotely? Read on!