Release planning with YOXEL SW: Starting a new release

May 17, 2007

The next several posts I intend to dedicate to covering release planning and release/project tracking. In agile terms, planning and execution of an “iteration/sprint”. Expect me to talk about YOXEL SW (our solution for software product management) quite a bit although I hope the details of the described process will still be useful in general, no matter which tools you prefer.

Release, Incremental Release, Iteration, Sprint

Some methodologies and tools like to talk about releases (longer term plan) and multiple iterations (short incremental chunks of work) within each of the releases. My terminology is simplified. Essentially I will use the terms release, incremental release, iteration, and sprint interchangeably. You start an agile incremental release and work on it for a month (call it an iteration or a sprint). Or you start a waterfall release, plan it for months and work on it for another year (call it a production release or whatever). So I will be using term ‘release’ and ‘incremental release’ and it will mean ‘iteration’ and ‘sprint’ too 🙂 .

Backlog

What I mean by backlog may differ slightly from what you think of it. My definition is very practical, the backlog is all requests in your request tracking database. The request tracker for our users is either Yoxel’s native tracker or a combination of an external bug-tracker (Bugzilla/Mantis/GNATS/…) and Yoxel’s. We understand that many teams out there already have their flows built around their favorite bug-trackers so we designed YOXEL SW to be able to connect to your existing bug-tracker and synchronize with it as often as you desire. It is up to you whether you continue filing all requests in your Bugzilla, switch completely to Yoxel, or separate bugs and simple enhancement requests from other classes of requests (requirements, feature request, customer support request) to file them in different systems. Your choice! In the end, Yoxel database contains all your requests: synchronized copies from your bug-tracker plus native ones, filed directly.

You can probably tell by now that my religion is to keep all requests (bugs, enhancements, new development, features,…) in one centralized database, even requirements and support tickets from your customers. Once you have done that, it is all about defining the right work flows for each class of requests to make it equally convenient for developers, product managers, and other involved stakeholders. Developers, support team, product managers even some of your expert customers file their requests into this centralized database where later the requests can be refined and acted upon. Especially if your system has hierarchical capability you can always break down requirements into a number of meaningful enhancement sub-requests, fill each of those with functional details, and have them ready for actual implementation.

Prioritized Backlog

It is better if your backlog is prioritized! One could think of using some complex ROI based functions (derived from win/loss analysis, customer questionnaires, risk assessments, … ) that rank all your requests in the backlog but Yoxel SW is pretty simple in this regard at the moment. All we use is ‘customer urgency’. Forget about so widely used and IMHO quite often confusing ‘severity and priority P1,2,3’. Just urgency as expressed by your customer: critical, high, medium, low. [I actually think that having all the data to apply the ROI based functions is good but I believe that the functions should be dynamic, meaning, they should order your backlog items based on the current focus of your incremental release/iteration. Sometimes your release is focused on a particular customer, sometimes on robustness of the software, sometimes on adding new functionality; the same order in the backlog does not work for all the situations.] Anyway, for now we prefer for product managers and stakeholders involved in the release planning process (which I will discuss in my next post) to define the exact content of the release based on their experiences and knowledge, backlog priorities are only used to generate preliminary release plans, to kick off the actual planning session. BTW, requests with urgency ‘critical’ are handled in a completely different manner, see my previous post about it Urgent vs. Planned.

Preliminary release plan

Once you have a prioritized backlog you need to take a chunk of the most important requests and start working on those, right? Well, may be not that simple. I agree though in one, you need to take a chunk to begin with, and lets call that chunk our preliminary release plan. Then, I believe, you want to collaborate with your team of stakeholders, prioritize the list of requests in the plan further, refine some of the items, make sure you have not missed anything, estimate and do whole lot of other interesting things. I will continue this thought in my next post …

YOXEL SW actually tries to simplify the generation of the preliminary plan for you, to make it a meaningful start point. Usually it is one release owner/product manager/scrum master who starts the release planning session. He/She simply fills out a simple form that drives an automatic plan generator. In that form he/she specifies a list of release members who will be collaborating and shaping up the final plan, objectives and goals of the release to keep all the members on the same page, and a requests filter. Depending on your release goals you may not want to grab the top N items from the backlog, instead you may want to be more selective (enhancements only, or requests related to these few customers only, or some other subset of the requests). Also the release owner specifies perfect fix/test time per request (based on your previous experience), % of time your team usually spends on critical/unscheduled/unexpected work (kind of backward way of specifying team velocity), and your desired deadline (for agile teams would probably be 2weeks-1month away). It is not very important to be accurate with all these parameters at this point (you can always refine the plan later).

The generator then makes an “educated guess” of how many requests your team can handle (and it knows quite a bit about your team too from the assignees and product definitions in the request tracker), given the deadline, and grabs that number of the requests from your backlog, after having applied the filter. It also informs all the release members that a new release planning session has started, with the specified goals, inviting them to take part in the planning session.

Your preliminary release plan is ready. From here on you are in the release planning mode, collaborating with all the release members to form the final plan that can then be used to drive your development/sprint/iteration.

Compare it with what you are doing today to generate the preliminary plan.

  1. Manually examine your bug-tracker for any important enhancement requests already filed
  2. Create Excel table with those enhancements plus potential new features
  3. Give it all preliminary priority
  4. Oh, yes, do not forget to include some important bugs
  5. And keep it all in Excel for now
  6. …. more manual steps?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: