Once again November has snuck up on me. Not only are we entering holiday season, in corporate America most of us are also entering planning season. (In non-corporate America and private life I think most of us procrastinate until the beginning of the new year, but I know I *should* be starting now.) Planning season and planning requirements can be especially tough For development teams practicing Agile development in a corporate environment. Corporate planning and funding processes usually aren't especially Agile-friendly so it's up to us to bridge that gap. If you're not in a corporate environment, the basic process can still make your own planning easier, faster, and more, well, agile. (You could even skip down to here.)

Historically, I/T and product planning cycles are based on a waterfall development methodology. The requirements phase of a product would be completed or at least partially completed in time for the planning cycle; costs would be estimated from the available requirements information. Alternatively, long projects might be in process and the remaining estimates updated for the next year. In-process projects were almost never cancelled because the sunk cost would then be forfeit - even if the remaining costs were rising or the product was no longer the best fit for the current market.

Predictability, planning, and measurement are the bywords for corporate planning. Most of us find Agile development to be a much more market-driven, streamlined way of working than waterfall, but that's not really going to fit easily into financial planning on an annual basis.

But don't despair! There are ways to make the two systems play nicely together.

Some things are easy to quantify and will just need to schedule into your agile process. These are usually planned technology upgrades (new version of Java, etc.) and the associated application changes to make them work, updates required to continue to work correctly with integrated systems, and changes required for legal reasons. These are easy - create an epic for each, break it into probably user stories, and make your estimates. Your financial planner will do the conversion to dollars but you may need to do a story point to resource requirement conversion. That's pretty simple to do based on your velocity - take your story points per iteration and divide that by the engineer and QA hours per iteration. Add some contingency time and voila, you're set.

New stuff is harder. The best way I've found to integrate Agile (and even Kanban) with corporate planning processes is to work on what I call Initiatives. This is a slight change in the historical focus on releases, but it's usually close enough for the planners to be comfortable working with them. Initiatives are usually functionally defined as an alternative to historical release definition. An initiative might be Online Payments, Live Help Integration, or even 64-bit Compatibility. By working within initiatives you can adjust the actual content as business conditions change while still forecasting the likely focus/direction of your work.

Don't let them fool you, the usual way of planning with Waterfall didn't mean that everyone always stayed the course. What it meant, though, was that a lot of time was spent replanning during the year and accounting for the changes. Initiatives are usually broad enough that some portion of them will remain applicable even over the course of a year even if the actual content and direction change dramatically. The planners and the company aren't usually as tied to the content as they are to the budget, which means that you really can satisfy both needs.

Define your initiatives first. They need to be high-level enough to be easily changeable in their details during development, but still at a level where the intent is clearly understood by everyone involved in the process. Don't forget to include maintenance and some cleverly-worded initiative for reaction to market changes/unforeseen needs. You can divide each initiative into epics so that you have some goals and direction defined without the user stories that would lock you into a specific detailed course. In general, unless you and your product folks have vastly miscalculated you should be able to make at least some progress on each of the initiatives over the course of the year. By tagging them in epics you'll be able to report your actual progress against planned progress very easily in pretty much any standard Agile tracking system.

Once you have your Initiatives and some epics to go with them, go ahead and give it your best guess as to how much and what kind of resource you'll probably require to implement. Realistically, this is as much detail as the historical planning systems have received and you'll remain Agile and able to adjust course as the business changes.

Now let's suppose you aren't developing software in a corporate environment. Even those of us with our own businesses need to plan for the next year. In general this process works for almost everything. Here are the ground rules:

1. You really can use Initiatives. (Remember, Initiatives are usually broad enough that some portion of them will remain applicable even over the course of a year even if the actual content and direction change dramatically.) In my own business, for example, I may want to devote a certain amount of my time and/or available funds for Marketing. I may know that I have commitments to existing customers. I may want to change my work mix so I'm doing more coaching and less project management. (Actually I'm doing my own planning cycle so I don't know the answers to any of these questions yet, but you can bet I'll break it down in broad categories.)
2. Attach a few goals and measurements to each Initiative. That doesn't mean that you plan out every activity the whole year, or that you won't change as your business changes. It does mean that you are going to develop focus areas to guide you.
3. Figure out how much you're willing to spend in time and money to achieve the high level goals you've listed. (You may need to lather/rinse/repeat - something might on further inspection not be worth the cost at the present time.)
4. Keep this info handy. Take a look at it at the beginning of every month and see how much progress you've made.
5. At least quarterly take a look at those Initiatives and goals and change them if you need to. This is a guideline - be Agile no matter what your business.
6. When you get into next year's planning cycle, pull out the original Initiatives and goals and all the monthly changes. This will help you in the next cycle.

Follow these steps and you'll be ready with some shiny new plans to start your new year.