On planning, part 3: forwards and backwards planning October 15, 2024

This is the third post in my series about planning in the context of agile teams.

• Part 1 is concerned with why you should plan at all.
• Part 2 describes my iterative approach to end-to-end planning.
• Part 4 explores the concept of the critical path.

In this post, I will explore what I call forwards and backwards planning.

As I wrote previously, before I can begin planning in earnest, I need to determine my current position and my goal (what ‘done’ looks like), and it is helpful to reflect on the means I have at my disposal to reach my goal. For the purposes of this blog post, I will assume I have done this groundwork already.

Planning forwards and backwards

I typically use this kind of planning for projects with deadlines because it helps me think about the dependencies between tasks and ensures that there are no gaps at the beginning and end of my plan. (See my previous post on why this is important.)

Planning forwards and backwards consists of three steps: planning forwards, planning backwards, and matching up both ends of the plan. Whether I start with planning forwards or planning backwards does not really matter, but matching comes last, obviously.

Planning forwards

Planning forwards, I think about what I can do right now that will bring me closer to my goal. I list possible steps to take immediately, then steps I can take afterwards, and so on. I write the steps down as a simple list, in the order in which they need to be done, taking care not to leave any gaps. Each step must depend only on steps appearing before it in the list. If there are any intermediate tasks^[1] to be done before the next step can be taken, these also go onto the list.

If steps can be done in parallel because they are independent of one another, I make a note of this to be considered later on, but I don't usually draw up a dependency graph or a Gantt chart or anything remotely complicated at this stage.

If progress depends on a 3rd party X to do or deliver something, this is also a step. The only difference is that I won't be the one doing it, and thus I will treat it as a black box and not iteratively refine it as I will do with other steps. However, I still need to think about the necessary preconditions for X to actually do their thing! Waiting for X while being unaware that X needs something from us before they can start is a failure mode I have seen time and time again. Because of this, whenever I add such a ‘3rd party step’ to my list, I try to put myself into their shoes and think about what I would need to get started in their place. If there is anything they might need from me (some artifact, information, or maybe just a trigger), I make sure to add it to my plan before the ‘3rd party step’.

If something needs to be done at a certain point in time, or cannot be done before a certain point in time, I note this when adding the step to my list. This is critical information because it constrains how I can move steps around later when trying to fit the plan to the timeline. All preceding steps must be finished before this step is due, and none of the following steps can start before this point in time.

Planning backwards

Planning backwards, I start with the desired end state and ask myself what needs to have happened so that we can say, ‘Yep, we are truly done now.’ This is the last step. And then I ask myself what needs to have happened so that we can take this last step. This becomes the next to last step. In this fashion I work backwards from the goal, always thinking about the preconditions that need to be true for the current step to be taken and the steps necessary to establish those preconditions, kind of like traveling backwards in time.

Often, there is more than one precondition or thing that has to be done first. This is OK. I write all of them down and pick one to continue the time travel, usually the one that seems most important to me. But I make sure to come back to the others later and deal with each of them. After all, they all are necessary to reach my goal.

After planning forwards and backwards for a while, possibly alternating between the two perspectives, each of the two plans will probably have developed several branches like this.

If the project is complex enough for the dependencies to be non-obvious, I might actually draw a diagram like this, otherwise, I'll make do with a linear list and keep the dependencies as notes (or sometimes in my head).

Matching up

At some point, the forwards plan and the backwards plan will begin to overlap, and it is time to match up the plans by connecting the branches of the forwards plan to the branches of the backwards plan. While doing this, several scenarios can appear:

• A step appears in both the forwards plan and the backwards plan. This is the simplest scenario, where I can just merge them.
• A step in my forwards plan is a direct prerequisite for a step in my backwards plan. Then I can connect the steps directly. I still need to check whether the step in my backwards plan has other prerequisites I need to connect.
• A step in my forwards plan is a prerequisite for a step in my backwards plan, but I cannot go directly from here to there. In this case, I need to amend the plan with the necessary intermediate tasks. If they are not obvious, I can reenter forwards or backwards planning mode for a while until I have figured it out.
• If a step in my backwards plan has prerequisites that are not fulfilled by my forwards plan, these can either be filled in (see previous point), or the forward plan is missing an important aspect entirely, in which case I will need to fill it in, either by planning forwards, or by continuing backwards planning until I eventually reach the area charted out by my forwards plan^[2].
• If a step in my forwards plan seems to lead nowhere, i.e., it cannot be connected to my backwards plan, I need to ask myself whether it is really necessary to reach my goal. Maybe it is a side track I can eliminate or pursue elsewhere, or maybe I forgot something in my backwards plan, in which case I need to reexamine it critically.

When I have matched up my forwards and backwards plans, I can be reasonably sure I have not forgotten anything important. At this point, I have a complete end to end plan, but I have not put it onto a timeline yet.

Timing it

For projects with deadlines, I put those down first, along with any other known time constraints such as the earliest possible start date or availability periods of critical resources. Then I try to distribute the steps of my plan around those ‘fixed points’ in a way that fits these and any other constraints (like ordering) I have identified during planning.

Once the initial timeline is complete, I do a plausibility check: is it realistic that we can do all this between now and the deadline? To do this, I need to estimate the duration of each task^[3]. If at all possible, I do this together with the people who are going to do the work.

And now?

Unless our schedule is very relaxed, the first naïve attempt at laying out my plan on the timeline will probably not look so good. If it does, all the better. If it doesn't fit, I continue by examining the critical path … critically. More about this in my next post.