Skip to content

Plans, Details, Dates, and The Future

I’ve been faced with a number of rather large planning documents recently, and it’s been making me sad. Some of them feel a lot like specification documents. There was talk of having hard dates attached to things, some of them far in to the future, which would have made the documents more brittle. Being a card-carrying, flag-waving, agile person this raises my hackles a bit. It got me thinking about planning and levels of detail: here's my (over-simplified, I know) take on things.

Plans should be more vague as they get farther into the future: the level of detail in them, and the dates attached to them. A good form of plan is a product roadmap. Even there, though, it can be tempting to go into deep detail and lock things into specific dates.

Less details the farther into the future you go.

Why less detail?

There’s no reason to go into lots of detail about things far in the future. Those things will probably have changed by the time we get to them, and we we want to be able to respond to change (rather than follow a plan). That’s where agile companies really shine: they learn new stuff and the plan and the doing of things bend a bit to take this into account. Marty Cagan talks about a related issue (things not working) in The Inconvenient Truth About Product.

Before development starts on a new bit of work, you should be building prototypes and doing user testing with them. This always results in some changes to the plan, and often results in rather large charges. You can't plan what these changes will be: you don't know until you've done your user testing.

I really like how Janna Bastow talks about roadmaps in her article Why Your Roadmap Should Be Flexible on Mind The Product. Her diagram is a great representation of the right way of thinking about scope / detail and time:

The flexibility of a roadmap in terms of time

Why not specify dates?

Things often take longer than we expect. Something far in the future will have a number of dependencies and things affecting it. Each one of those things will have been scheduled based on estimates. In Coding, Fast and Slow: Developers and the Psychology of Overconfidence, Dan Milstein talks about how it's essentially impossible to make accurate long-term estimates.

Another reason to worry about including dates is that they often get taken as absolutely fixed deadlines. John Peltier talks about this, and how to manage dates and deadline in a roadmap in his article Product Roadmaps: Drop The Dates.

Okay, but what about when a date really is fixed?

Then you invoke the Iron Triangle. Sure, you can definitely have a thing on that day. But it might not be what you expected.