If you work with others to build software, you will be familiar with the term planning. You’ve heard the term being thrown around in sentences such as “next week is planning week”, “we have to get better at planning next quarter”. Heck, you might have even participated in said rituals. But if you’re like me, every time you come out of planning, there is always this voice in your head thinking: Have we done enough?

After many iterations of planning at different time scales from daily to yearly, I’ve finally come to understand the source of my lingering doubt.

As the person responsible for a team’s planning outcome, I realized that I’ve always had to serve two distinct audiences: the stakeholders, and the team of builders. They have different goals when it comes to planning, yet without explicitly stating them, as I was subconsciously swaying between satisfying one or the other, that’s when the doubt of insufficiency crept in.

To be effective in satisfying both audiences, we have to dive into what they’re in for.

The Stakeholders

The typical stakeholders of a software building team include higher level managers, other teams, their managers, and possibly executives. If they’re ever part of a team’s planning, chances are, they are there to find out, and possibly negotiate, what will be done by when.

For higher level managers and executives, this is important because, as the ultimate resource allocators, they have to keep an eye on the return on their investment, in the form of people and time. For example, knowing how many engineering weeks it would take to integrate with an external service provider might be a very important factor in them deciding whether they’d make the purchase.

For other teams, participating in planning is important to coordinate their dependent projects, as well as benchmarking their own project execution. It could be a customer-facing team interested in when the next version of an internal tool will be released, or it could be a sister team about to start a similar migration and is interested in how much effort there would be.

Ultimately, stakeholders’s goal from planning is to gather information so they can make future decisions. As a result, the view we present to stakeholders during planning should focus on expected outcomes – what will be achieved, in what order, by who, by when, with what value, and what risk.

The Builders

On the other hand, for the people who are actually building the software, they mostly come to planning simply to receive their next batch of work.

The game for them is simple. The more details and certainty there is, the more predictable and smooth their execution will be. In the most extreme case, if every single piece of requirement and specification is laid out, with all the edge cases accounted for, and assurance that nothing will be changed, most engineering teams can deliver exactly what is being asked for with high accuracy. On the other hand, if there are many ambiguities over how a system should behave, especially in unexpected situations, the room for poor design and execution gets larger and larger, to a point where entire systems may have to be redesigned and rebuilt from scratch.

As a result, experienced engineers will be on the lookout for ambiguities during planning and will attempt to clarify as many points of contention as possible to avoid going down the wrong path.

Therefore, the view we present to builders should focus on scope (i.e. what concrete behavior the system should exhibit, ideally with priority of importance) and design (i.e. what technical components or structure needs to be there to afford the behavior), so they can have confidence to deliver their work.

Coming together

In summary, the stakeholders want predictable outcomes, while the builders want enough details to get their work started. But.. how can the team commit to an outcome without sufficient details, and how could there be concrete scope if important decisions about the project were not yet finalized?

That’s right. It’s not possible.

It’s not possible because I may have tricked you into assuming planning is this one full day, or at most a few days, of non-stop meetings where all decisions are rapidly made and all plans are readily finalized for a quarter or even a year.

But in reality, a well thought-out plan has to be an iterative process. Product team needs time with customers to develop and validate ideas. Product and engineering needs time together to converge on a compromise between functionality and feasibility. The technical team needs to evaluate design options and trade-offs. Analysts need to pull numbers to assess impacts and risks. Managers need to negotiate with each other on personnels. Department heads need to align on wider priorities.

All these conversations take time and rounds of back and forth to reach a conclusion. That is where the real planning happens.

If you’ve taken the time to have these conversations, hopefully you wouldn’t feel as inadequate when the new quarter starts.