As agile practices have taken over the world of software development, the amount of planning done by teams has shifted. Many teams have moved from a waterfall process with an overabundance of planning to lightweight processes with almost no planning. Finding the right spot on this continuum is difficult. I often feel like Goldilocks, trying to have not too much planning and not too little, but just the right amount.
It’s important to start with your context and goals when deciding how much planning is the right amount. In the early stages of a startup, the cost of doing very little planning and learning as you go is relatively low. When your whole world is unknowns, the value of planning is almost zero. In many cases, it’s better to start coding quickly and validating assumptions. The cost of making a mistake is low. You don’t have nearly as much code to change, and your customers tend to be much more forgiving. Beyond these very early stages, the right level of planning is harder to determine.
If you ask software developers why we create project plans, one of the first answers you’ll hear is, “So we know when something will be done.” In some ways, this is true, but maybe not directly. I’m less interested in the date of completion than the amount of work required for most features. By projecting a ballpark level of effort, I can decide if a feature is valuable enough to invest time.
For me, the primary purpose in planning is risk reduction. By doing the right amount of planning, we take many unknown unknowns and start turning them into known unknowns. That sentence may be confusing, so let’s make it a bit more concrete. We recently changed the library we use to handle file uploads from the browser. To plan for this change, we made an inventory of every part of our code that integrated with the existing library. From there, we looked at what features were used by the old library to make sure we knew what would be required in the new library. Finally, we prototyped replacing just one of these touchpoints to ensure that the new library functioned in production. By performing this little bit of planning, we were confident that switching libraries would be possible and wouldn’t negatively impact any other work we had planned. Along the way, we also learned that we used a feature not supported by our new library. This allowed us to intentionally decide upfront if we wanted to deprecate that feature, find a new replacement, or stay with what we had. If we had started coding without planning, we likely wouldn’t have found this issue until we were halfway done, leading to fewer options for handling this issue.
For a relatively small feature, the amount of planning required is quite small. For much larger features, we will need more planning. But how much more? We certainly don’t do ten times the planning for a feature ten times the size. Instead, we keep the same goal in mind, turning unknown unknowns into known unknowns. For instance, we planned a major new project that we expect to take several years to complete. All told, the planning for this project took approximately three weeks. That included defining our goals, breaking those goals into more significant milestones and streams, and the initial breakdown from there into high-level task lists for each stream. Along the way, this planning process forced us to think through each stream in much more detail than we had done initially. This thinking brought up several decisions we needed to make, which changed how we felt about the project. It wasn’t the planning itself that reduced the risk. It was the detailed thinking that was caused by the planning. The result is that we needed to change our initial plan in significant ways to hit our milestones due to several unexpected dependencies discovered in planning.
At this point, you might be expecting me to instill some great wisdom as to how to decide how much planning you need to perform. Sadly, I don’t have a definitive answer. Over the past twenty years, I’ve sometimes planned too much and sometimes planned too little. With time, I’m more likely to be in the right ballpark. Like many things in technology, I try to find the goldilocks zone of planning – not too much, not too little.
While I can’t give you the formula for the right amount of planning, I can give you some signs that your current level of planning is off. So, with apologies to Jeff Foxworthy, you might be under-planning if:
- You often find new requirements that make you go back and revisit core decisions.
- You get to what you think is the finish line only to find out you aren’t done.
- Your end-users say things like, “That’s nice, but what I really need is …”
- One of the technologies you pick isn’t suitable for your intended use.
Similarly, you might be over planning if:
- The planning takes almost as long as the building.
- People give up on projects because they never seem to get done.
- You are repeatedly asked when work will start.
- You never find new requirements in the middle of development.
So, listen closely to the decisions you make, and try always to come a little closer than you did before.
