Release Planning

My release planning is a little different than other agile teams I’ve encountered and it deviates somewhat from what I believe the excepted method of developing one is, as well.  In any given iteration we work on 10+ user stories concurrently, those stories can account for many different products and or projects. Because of this I combine all projects into one plan, mostly because makes it easier for stakeholders to review the workload at a glance but also because it assists with making priority decisions at a comprehensive level.

I start off with a list of all projects that I am aware of, categorized by the department requesting and the type of goal it is meant to achieve.  I then do some initial resource allocation bumping this list against my resource availability.  This gives me a starting point with which to have conversations with my management and also my customers on priority and scheduling. Once those conversations are completed I can then add in any additional projects that have been requested and go through the process of resource allocation once again to come to a best guess calendar view.

Typically at this point I have resource issues, I haven’t had a year yet where I didn’t have more projects on deck then were humanly possible to complete in the year. This state begins the process of negotiating what projects we’ll do, what resources we’ll need and where we can scale back or scale down functionality in order to fit it all in.  Here’s where the types of goals assigned to each project come in handy; something that is a technology initiative rarely has as much weight as something that is to retain customers or increase revenue, including those sparks great conversations.

Once we’re through this step, I have an almost final project list; we only need to bump it up against the company initiatives for the year to make sure we’ve weighted the projects accurately based upon their direct impact to organizational goals.  Most of the time not much changes, we’ve already done due diligence on the initiatives, my product owners are all aware of the high priority projects or goals and products being released so we’re typically in line with expectations. I still think it’s worth it to do the pass though, just in case. Easy enough!

At this point I will assign resources and add in some cost projections to assist with any further conversations we need to have over acceptance and priority. Which gets me to the for-now-final copy, I am pretty much done until a new priority or initiative pops up, which happens regularly of course. You may ask – What is the point of spending all of this time and effort into a plan that is only good the day it is written? It provides a very simple, straight forward level of transparency into our process, how we make decisions and the impact of changes. All of which I think are key to effectively managing expectations even if the plan we start with doesn’t resemble at all where we finish.


Comments are closed.

%d bloggers like this: