I've been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change.
I suspect the first question is how much change do you need in your product, not how good your information is, or how much planning you need.
The data you need and the planning you can use will change with respect to where the product is in its lifecycle.
Where Is Your Product in Its Lifecycle?
Every product has a lifecycle. This is my adaption of Geoffrey Moore's crossing-the-chasm idea with what customers want at different parts over the product's life.
The more customers want time to release, the more often we need to change our plans.
Long-term plans don't mean much if you are trying to cross the chasm.
If you're in the later part of the product lifecycle, you need a balance of projects in the project portfolio. You'll want to exploit this product for as long as possible. And, you'll want to create experiments, with a high rate of change. Those experiments will become other products to take the place or add to this one. (See the various kinds of products in Tactical Ideas for Agile Budgeting, Part 1 or in Manage Your Project Portfolio.)
The more change you want, the more often and the smaller you need to plan. And, you might need different data than you have.
How Long Does Your Information Have Value?
What kind of data do you ask your teams to generate? Many of my clients ask for some form of estimation on the various feature sets.
Instead, I recommend you ask for other information: the Cost of Delay for a given feature or feature set and the team's current cycle time. If we're lucky, they have cycle time for that feature set. If not, we have an idea of a team's capacity.
Why cycle time instead of anything else? Cycle time is the time it takes the team to generate something useful. Story points won't get you that. An estimate is likely to be wrong. Cycle time is real historical data.
In addition, you can estimate duration with cycle time, just by counting stories. I wrote about that in Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets and in Create Your Successful Agile Project.
Consider the Cost of Planning vs the Duration of the Product's Life
All planning costs money. The more detail you want in preparation for the planning, the more it will cost you.
The faster your data “expires,” the more gathering the data will cost you. If your information changes fast, it has low persistence. The more you base your information on estimates, the lower the persistence.
If you need to change this product fast or experiment to discover alternative products, does it make sense to gather a lot of data for product planning?
I much prefer small, safe-to-fail plans and experiments. Not just for experimental projects, but for all the planning activities.
Consider these truths of plans and software product development:
- The faster you can deliver something small and repeat that every day, the lower your cycle time is. You can predict the probabilities of delivering a given thing much easier.
- If you require more change, lower cycle time and more interaction with the customer will help more than plans.
Do you even need large plans? I like strategic plans that say, “Here's what we want to be known for and here are our strengths.” You can build outlines of deliverables for those strategic plans.
But (tactical) detailed long-term, quarterly or yearly plans? If you chose an agile approach because you need change, I don't see the value of a lot of tactical planning.