Agile Release Planning

A software release may result from multiple iterations (or ‘Sprints’ in Scrum).

Sprint Planning is about planning what’s included in the next iteration.

Whereas Release Planning is about planning multiple Sprints, in order to predict when a release (or releases) might be delivered.

Release Planning is a very simple way of doing some top-down planning. Much less complex than a more traditional project plan on a Gantt-chart. Therefore much quicker to do. And, I would say, no more or less accurate.

First of all, let’s assume you already have your Product Backlog (feature list), with all your User Stories set out in priority order. Let’s also assume that you’ve estimated your product backlog, ideally using Story Points.

If you already have an established team doing Scrum or XP (eXtreme Programming), use the team’s known Velocity to divide the Product Backlog into Sprints.

However, if the team is not already using Scrum or XP, you need to estimate the team’s Velocity. To do this, you must first make an assumption about the team size that is likely for the release. Then, you need to decide on your Sprint duration and, ideally with the input of the team, decide how many of the initial User Stories you think could reasonably be achieved in a Sprint. Add up the Story Points for these items. Using this number of Story Points as the team’s estimated Velocity, divide the Product Backlog into Sprints.

If the project team is not already established, add a ‘Sprint Zero’ at the beginning to get things ready for the first Sprint, for instance getting the team organised, briefing meetings, setting up development and test environments, preparing the first set of User Stories, etc.

If it’s a large or complex release, add a ‘Stabilisation Sprint’ (or more than one Sprint if appropriate) at the end to stabilise the release. By this, for instance, I mean stop adding new features, complete regression testing, bring the defect count down to an acceptable level, prepare for deployment, etc.

If the predicted end date is not acceptable for the project’s objectives, alter the assumption about the team size (and associated costs!) and re-calculate.

And there you have it! A Release Plan that provides an outline of the Sprints, what’s included in each, and an estimated date for the release.


6 Responses to “Agile Release Planning”

  1. Nathan says:

    Isn’t this somehow going back to a waterfall approach when trying to plan what will be released and when?

    I can see a customer not willing to make an application public until some critical stories are developed. In any case, delivering a “potentially shippable” product to the customer at the end of each sprint gives the customer the freedom to consider the application releasable, or not (whenever that may be).

  2. jbisotti says:

    You had me until the “Stabilisation Sprint”. If you get to the end and you need such a sprint, or sprints, then you were fooling yourself during the earlier sprints when you claimed the work item was “done”. “Done” means tested and ready to ship. Either you were fooling yourself, or the Scrum Master was not doing their job very well.

  3. Kelly Waters says:

    Hi, this is my response to Nathan…

    Re your first question, “isn’t this somehow going back to waterfall when trying to plan what will be released and when?” – an agile approach doesn’t necessarily mean a lack of any planning.

    Even if there’s a release plan, the scope can be varied throughout the development, with features being added and dropped and the release plan being adjusted if necessary.

    Realistically, it’s unlikely many customers, internal or external, will commit to any significant project funding without some idea of what’s likely to be released and when.

    A key difference though is that it’s not based on tasks and hours and dependencies all mapped out in detail on a gantt chart that attempts to understand all the deliverables. It’s just based on the number of story points the team thinks it can do in each iteration and chunking up the features on the initial product backlog.

    In any event, you’re right about the product being potentially shippable at the end of each sprint. That certainly is ideal, but my comment on this point was about “releases that are large or complex”, and therefore it may well be impractical to release the product until core features are present, even if the completed features are production quality at the end of each sprint.


  4. Kelly Waters says:

    Here is my response to ‘jbisotti’…

    You questioned the need for a stabilisation sprint. For small releases, I would completely agree with you.

    But let’s be honest, in practice on a large or complex project with a large team developing a ground-up product and spanning several sprints, there always remains the possibility of making changes that affect features that were already signed off earlier in the project.

    Now of course I realise that if you have a great design with little dependence between features, automated unit tests with 100% code coverage, automated regression testing, and do not suffer from human error, this risk might be low. But in my experience, in practice this isn’t usually the case for large projects and some regression testing and rectification is usually needed once the scope is completed.

    And on a large release, like a ground-up development, this last sprint (in our case they’re short sprints of a couple of weeks) might be needed just to do this regression testing, resolve any final issues, complete final load testing, prepare for deployment, etc, etc.

    You might not agree with the term “stabilisation sprint”, maybe it’s just the last sprint of the project.

    If it’s not needed, then clearly that’s great! I’m certainly not saying it’s compulsory. And I certainly wouldn’t want to see it after a small business-as-usual sprint.

    But, on a big project involving a large team and spanning several sprints, I’m just acknowledging what I think is probably the reality for many project teams, however experienced they might be in agile development.


  5. Arun says:

    jbisotti, Kelly,

    I do understand the perspective from both of you and tend to agree more with Kelly; with reality that in each sprint, we typically expect functional test cases as priority for acceptance.

    Although performance testing may be equal party for acceptance, But unless we have all the sprints that may compose of several teams and sprints, one-shot performance test may be good to get actual performance that can be expected in Production. And larger teh ammount of functionality packed in release, more the time which may not fit in previous sprint completely.

    Also vulnerability testing is another part which can best be done with stabilization Sprint.

    The cost of doing perfefct testing in incrementally regression via each sprint is much higher as compared to stabilization Sprint cost.

  6. Jesse Chunn says:

    I think the question of a "stability" sprint is more of a semantic debate. You could easily have stated it as a list of "lower priority" user stories, such as: "As a clerk, I want to get the results of my query back in under 2 seconds, so that I can complete 20 widgets per hour." In "stability" sprint terms, that just means performance tuning. The same might be done with vulnerability tightening or other types of things that may be best left for the "end". Also, it is a simple reality that as more code is piled in, the risk / chance of regression issues grows exponentially, so (as suggested) larger projects will be more likely to need some final "stability" tweaking. As someone else mentioned, it is just too time consuming to do complete regression testing during every sprint once the amount of "new" code gets to a certain size. That is not to say that the result shouldn't be potentially shippable, but a little "clean-up" at the end of a major "release" is reasonable and indeed responsible.

Leave a Reply

What is 2 + 4 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”