How I Plan Software Projects

In the past few months, I've worked on projects with several different teams across my company. I've noticed different styles of planning and executing projects, which has caused me to reflect on the system I've developed for project planning.

For this post, a "project" is a unit of work requiring coordination among multiple people and possibly numerous teams. Work that can be done in isolation in a day or less isn't a project. It may be important, but it doesn't require much team coordination.

Big Picture

I am a "work backward from the end goal" planner. I set an end goal, envision an ideal state, and work backward. However, I keep in mind that my end goal will shift as I learn more about the technical implications of the work.

Work back in enough detail to know the main steps, where the risks are, and your decision points. Decision points are especially important. Every project can be walked back in the early stages, but there comes a point where you are committed to keeping at least some of the work you've done.

In a recent project, I set the end goal and clarified the business outcomes in the project name. This project was easy to sell to others because they instantly saw the value in the title. The early milestone in this project was quick and easy and proved the value of the work early. Later milestones were more complex but continued to deliver the same goal.

Break it Into Milestones

I always ship multiple milestones. Too many projects fail to deliver because they are built from the ground up without proving value and testing the work.

I find getting early feedback on small milestones easier than tackling the hard parts first. With this early feedback, I then apply what I learned to a harder problem set.

I usually pick the second milestone as a more complex, gnarly problem. This way, I have quick feedback from he first milestone and then time to strategically apply it to a problem that I know will be difficult.

Decision Points

I find my point of no return. It is rare in coding projects to be able to walk away from a failed experiment entirely unless you know your decision points.

When are the best times to collect early metrics and measure your success? At what point will I be so deep in the work that rolling it back would have technical consequences?

If I find my point of no return early in the project, I reconsider my plan and delay it as long as possible. I often develop a Parallel Change or expand-contract pattern to avoid this point.

I collect data for my decision points and know what data I need early on in the project. Defining metrics before I start writing code ensures a project's success and simplifies questions that lead to scope creep.

Detail Each Task

Now comes the less fun but necessary part. I often do this task with the whole team. By this point, we've decided on the scope of work and understood the critical decision points.

We now break up the milestones and make tickets for them together. I've done this over calls, where someone plays a lo-fi hip-hop playlist, and we each work our way through a section of tickets. Then, finally, we review the tickets as a group so we are aligned on the direction and detail of the work.

Depending on the project's scope, doing this work every two weeks or so is good. Too much detail too far into the future becomes wasted work. So, I ensure that we work through one milestone at a time and have enough work planned out to fill the next week while making room to pivot as needed.

I detail tasks in a language that anyone on my team can understand. One-line tickets or tickets with only a title are banned.

Ideally, a new team member could join the project, pick up a ticket, and get enough context to understand the ticket's intent, even if they don't understand the whole project yet.

I follow a standard template for tickets:

## Context

The context section explains how the work fits into the
greater project and why we need to do it.

### Developer Notes

This is the gotcha section. I don't solve problems in
here, but I list potential gotchas or things to be aware
of.

### Acceptance Criteria

Here, I define "done." What needs to be true for this
ticket to be done?

Most importantly, I do not solve the ticket in the description. The ticket defines "why" and "what," not "how."

I trust the developer picking up the ticket to decide how they will do the work.

Iterate, Measure, Modify

Once work is kicked off, frequent check-ins with the team and frequent check-ins on metrics help guide the work. The big vision I started with is rarely where a project ends up, and that's good. I expect my projects to take shape as we refine the work.