Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Release Planning at scale

Last post 01:59 am March 7, 2015 by Ian Mitchell
6 replies
10:48 am March 4, 2015

HI People

Just reading around release planning and have a question around scaling it up for multiple dev teams.

We currently have 4 back end dev teams and 4 front end client team all running there own sprints. I was wondering what the benefits are of release planning and how, where, whose involved and when in the cycle does it happen.

Also how do you synchronise back log items that go on a release plan and items that go on sprint back log. Do you ahve 2 lots of back log items.

Any help appreciated.


01:53 pm March 4, 2015

I've done different techniques in various companies. With my current employer, we are using epics to organise a set of user stories into a coherent customer-facing deliverable.
The epics have a target release defined, and there is either a technical lead or a project manager responsible for talking to the various Product Owners in the front-/back-end teams and making sure their priority and sprint planning takes the overall goal and release planning into account.
With JIRA (our tool of choice), you can use various epic reports to track the same.

We discarded the idea of single backlog across teams (or parallel backlogs) since management of said backlogs became too challenging.

I can go into more details of course - depends on how far you'd like to go.


04:31 am March 5, 2015

Separate front-end and back-end teams will usually need to co-ordinate their release plans in order to deliver features of business value. You could therefore reduce the amount of release planning needed by re-organizing into feature teams instead. This will make it easier to orient a release plan around business needs rather than technical ones.


05:50 pm March 5, 2015

Feature teams often bring more challenges than they solve. They don't work well when you have many small projects going at once, and they don't promote in-depth knowledge of specific components or engineering-driven improvements.

In some organisations they do work, but it's not the ultimate answer to the release planning question.


07:53 pm March 5, 2015

The first consideration in release planning is to eliminate Development Team constraints. The focus must be placed squarely on the value that is yielded by each release to the Product Owner. Feature Teams are not essential to Core Scrum but they are a good practice, and hence their merits are given particular consideration when implementing Scrum at scale.

Development Teams that are not organized in terms of feature release are more likely to increase release planning overhead, including the communication that is needed to effect a release and having to resolve multiple integration points before the value of any one feature can be evidenced. It is therefore important to consider this matter first when optimizing release planning arrangements.


09:54 am March 6, 2015

Theoretically this is all correct. Practically, feature teams come at a cost for the reasons named in my previous reply.

To add to that, developers do not work solely on one product or feature. They also support junior team members, deal with customer escalations, do maintenance on a component, have older projects that are being deployed etc. All of these require daily interaction between component owners, and feature teams go against that.

They are definitely worth considering though. From personal experience, tried feature teams on several occasions - each time performance was worse than with modular teams.


01:59 am March 7, 2015

Feature teams may go against organizational assumptions about value and how it is best delivered. These assumptions are often reflected in an organization's configuration, such as by layer or by geography or by component.

Enterprise agility requires deep and pervasive change, and the sponsorship to achieve it while an organization is in flight. A dip in productivity is to be expected when implementing feature teams, although it is a short-term one. This is recognized in the Scaling Professional Scrum framework. However, I'd personally agree that it would not be wise to set about implementing feature teams unless the appropriate sponsorship to do so is in place.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.