4 min read

TPP #010: Planning to succeed

TPP #010: Planning to succeed

Hey, friends. 

Today I’d like to talk about curiosity during planning: 

  • Why teams lack curiosity during planning 
  • Developing a curious outlook for planning 
  • How to build a planning checklist for your team 

No questions. No Plan.

It was the third or fourth planning meeting I had observed for Team Ping Pong. 

The pattern was clear. Planning was more about ensuring that everyone had work assigned than discovering what to build. The meetings were as long as the team’s morning standup. 

And their results showed it. 

Teams lack curiosity for a lot of reasons: 

  • It’s actively discouraged – Someone decided that developers should just do what they’re told. 
  • Fear of uncovering unexpected work – Things can really go off the rails if you figure out that your “small” story is really complex. 
  • Fear of admitting you don’t understand the work – Developers sometimes get confused about the bigger picture, and asking questions exposes this. 
  • The work never starts because of analysis paralysis – Once you start asking questions, someone will need to decide what to do. 
  • Nobody knows the answers when questions are asked – And in some cases, everyone is equally in the dark, not sure what to do next. 
  • Etc. 

But it’s pretty easy to adopt a curious outlook when planning. 

How to be more curious during planning

I recently came across an article about doors in video games

The author describes the surprising depth of thinking required to implement something as simple as a door. It’s not enough to just add doors to the game. You have to also understand how they behave. And for every decision there are second-order effects. 

A summarized list includes: 

  • Can doors be unlocked and locked? 
  • What tells a player a door is locked? 
  • How does a player know they can unlock a door? 
  • Does the player need a key? 
  • Does the door lock again once they close it? 
  • Etc. 

The article is a good reminder the importance of curiosity in planning your work. 

So, how can your team develop a curiosity during planning? 

Here are a few things that I’ve seen work well: 

  • Designated questioner – Pick a member of the team to just ask questions during planning. Their only job during planning is to ”think outside the box” and ask interesting questions about the work. 
  • Five Whys – Use the five whys technique to dig deeper during planning and ensure everyone is on the same page about the work. 
  • Develop a domain-specific checklist – This one is my favorite. Start keeping track of missed tasks, scope increases, and defects. Use those to build a checklist of questions to ask for every user story during planning. 
  • Crazy Eights – A brainstorming technique like crazy eights can help unlock questions and discover new ideas about the work, all through drawing ideas. 

Building your own planning checklist

Having a repeatable checklist of questions to ask is a game changer. 

You’ll surprise yourself with how much faster planning goes. And how many new tasks and scope you uncover when you adopt a checklist. But you need the checklist to be concise and (ideally) domain specific. 

So here are some things to keep in mind as you build your checklist: 

  • Are user personas clearly defined? 
  • When and how to users use the system? 
  • Where do most of the defects in the system originate? 
  • What goals and expectations do users have for the system? 
  • What characteristics of the system require the most attention (e.g. scaling, performance, usability) 
  • Etc 

Let’s extend the example above about doors in video games. 

Chances are, there are similar questions about other things you might add in a video game. Mostly about behaviors. But also about state and user interaction. 

A checklist of interesting questions might look like: 

  • Does it always behave the same way throughout the game? 
  • How do users know they can interact with it? 
  • How do enemies interact with it? 
  • Can users interact with it? 
  • What states does it have? 
  • Etc. 

So, to develop your own checklist: 

  1. Review the questions about your system. 
  2. Identify patterns and repeated tasks. 
  3. Generalize those patterns into questions. 
  4. Start using your checklist during planning. 
  5. Inspect and adapt your checklist after each planning session. 

Clay’s notes

Improving your planning is the easiest way to improve your output. 

By injecting some curiosity into the process, you’ll learn about “unknown” work a lot earlier. 

And in doing so, you’ll start to notice patterns. 

Patterns which can turn into a checklist. 

Happy planning! 👋