In project management, your daily goal is to move the development needle along while monitoring and controlling costs without compromising quality. The best way to accomplish the task at hand is by having an agile release roadmap to better assist development efforts. Hopefully, by the end of this blog, you will be better prepared to implement Agile Release and Iteration Planning in your organization.

Related: Why You Need a Roadmap for Agile Development


Let’s start by breaking down the key terms we all need to know.

Agile is relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans also known as an iterative approach.

Release Management is the part of the software management process that deals with development, testing, deployment and support of software releases to the end user. In the new era of continuous delivery (CD), organizations have become increasingly lean and agile while managing this process. Release management is always managing, planning, scheduling, and controlling software delivery throughout the release lifecycle.

Iterative Development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles.

Agile Planning is nothing more than measuring the speed a team can turn user stories into working, production-ready software and then using that to figure out when they’ll be done.

A retrospective is looking back on or dealing with past events or situations; an opportunity for the Scrum Team to reflect and create a plan for improvements to be enacted during the next sprint.

Now that we got that out the way. Let’s move on the good stuff!


The iterations are necessary evils to keep release management honest, reasonable, and provide the Product Owners (POs) with real estimates of expected development for a specific period of time. Iterations can be anywhere from 1 to 3 weeks and should be focused work blocks commitments from the development team (engineers and designers). The idea of iterative planning is not to plan to work, but rather to work the plan. The late and great Albert Eisenhower said, “Plans are worthless, but planning is everything.”

The upside to planning is the opportunity to assess how well your planned activities were executed, and discuss what problem impacted the planned work which can be conducted during the retrospective. At stable|kernel, we have retrospectives regularly internally with sk project teams only or externally which includes our clients. These opportunities to gather allows for everyone to receive affirmations and feedback as a team with the primary goal of having the next sprint of work go just as good or better than the last.


Think of releases as opportunities to provide valuable feedback on finished work. This feedback should come from POs and End Users (EUs), if available. The importance of feedback IS to make sure the original functionality is working as expected or resolve design or user experience issues. Feedback IS NOT for making suggestions or recommended feature changes; feature changes should be noted in your project backlog and prioritized for the next release.

Basically, if a finished feature meets the acceptance criteria outlined, do not change acceptance criteria POs (ahhh! scope creep) unless absolutely necessary. Sticking to release candidates will help accomplish important milestones such as EUs demonstrations, pilots and version 1.0 releases. More importantly, why increase release timeline and/or budget if you don’t have to? Also, you may make a valuable change that may be costly later.

In my humble opinion, it is best to “go to market” sooner rather than later so you can get valuable EU feedback as the next release kicks off.  The goal is CD to the EU’s to keep a high engagement, deliver on most valuable features each release candidate, and anticipate trends and market changes.

In order to have an on-time release candidate with high quality without going over budget, it’s recommended to do the necessary work up front. Don’t skip the planning and maintain the release plan as a living document of what’s to come.

Here at stable|kernel, our goal is to provide a solution to each and every client in a consultative approach. We want to assist in solving any problem your business may be up against, and we want to do it with high quality, outstanding development within the budget and time constraints.

Leave a Reply

Your email address will not be published. Required fields are marked *