Release Planning Answers the Other Questions, Too

The answer is release planning. Some days, it doesn’t seem much like the question matters: The answer is usually release planning.

When we talk about release planning, we mean looking medium-term at the next big deploy or release that your customers are going to notice. We will have a persona or two that we’re trying to please and a backlog of features that all fit together to form a cohesive whole.

Sticky Notes lined up on a table

What Release Planning Delivers

The output from the release planning activity is a well-groomed backlog describing the included features. Because of this, we think feature decisions are the only thing driven by release planning.

This couldn’t be further from the truth. Yes, release planning answers the business question of, “Do we include feature X?” But it also answers the technical question of, “How do I build feature Y?”

How Release Planning Drives Decisions

Every day, software developers make innumerable trade-offs. For example, I might implement an asynchronous feature by pulling in a real-time notifications service. While these can be great, they can also add costs, extra libraries, more services to monitor, etc.

If I have a large number of things that will be asynchronous, it makes sense to choose this route. If this is the only such feature, then simply having my web browser poll for completion will go faster and reduce points of failure.

It’s obvious that pulling in a new tool tool is only useful if we are using it a lot. I think the obviousness makes it hard to talk about, because of course you should consider the impact! But without a release plan, you cannot do so effectively. The plan lets you see which things might be impacted (positively or negatively).

Put another way, if the only plan you have is short-term, you cannot make smart long-term investments. The release plan is the long-term vision that you need to make better investments in your project.

All of the questions below–regardless of how technical they are–can be better answered in the context of the plan:

  • Choice of platform
  • Choice of library/component
  • Focus on performance measurement & improvements (… or not!)
  • Choice of test data (volume vs. variation, character sets, etc.)
  • Ramping in new developers vs. plowing ahead
  • Level of visual polish
  • Dealing with technical debt

How Much Planning is Enough? How Much is Too Much?

For a long time, the so-called “waterfall” method suggested creating a very complete plan up front. We know better now. Creating the plan at the point of maximum ignorance does not tend to add a lot of value. On the other side, the Agile movement once said “YAGNI” or “You Ain’t Gonna Need It,” which suggested just keeping your head down and working on the next thing. That doesn’t work so well either for all the reasons described above. (See Martin Fowler’s commentary for a similar conclusion.)

Atomic’s Process

Atomic’s “Research, Design, and Planning” process was created to fit in the middle ground: to focus on the pieces that provide the most value and get a good definition that can drive decisions and let you move forward. You can read more about what a kickoff at AO looks like, and consider Brittany’s thoughts on how to get a project teed up with maximum chance of success here and here.