release scope management
Release Scope Management seems to be a simple process and it is in deed if certain mistakes are not made. Here is our list of release scoping mistakes to avoid:
Not considering all stakeholders' interests
Considering all interests with the same weight
Taking release scope management as a one-time act or having only one scope review step in our release process
Trying to manage release scope without having a set GOLIVE date
In details:
Mistake #1 - Not considering all stakeholders' interests
Have a look at the release manager chart to see how many different interests/forces are forming a release. (and that list of stakeholders could easily be longer):
It is easy to see that Business, Solution Architects or Testing have totally different approaches to the release process and its priorities. And it is normal. Each silo of stakeholders should have their own unique understanding of their work-priorities but it is the release managers' job to harmonise these different interests. And release scope management is in the centre of this harmonisation effort. The best practise we follow is to have separate meetings with all stakeholders before a joint release scoping. This way release management can be prepared for all different views and the release manager can help other parties of stakeholders to be prepared for all articulated arguments.
Mistake #2 - Considering all interests with the same weight
Though all stakeholders must have a say regarding release scoping, it is important to for all participants to clarify, that those interests do not represent the same voting power. According to our experience it is helpful to allow every parties to articulate their views and concerns but only in a controlled framework of clear hierarchy. It is the release managers's job to clarify before the release scoping process that certain stakeholders represent decision making power while others can only escalate certain issues and finally there are stakeholders whose only role is to articulate arguments, concerns, considerations or risks but cannot make any decisions about them.
Mistake #3 - Scoping a release as a one-time step
It is a common misbelief that release scoping is a one-time act per release, usually at the beginning. But reality is closer to some more release scope reviews albeit by delays and technical issues so SDLC reality forces all of us to review our release scope more often. Hence my preferred approach to this challenge is to plan scope review points on our way to GOLIVE. And there is no better moment to do so than at the release gates. In most cases it is a quick yes or no question if we need to review the scope, as it should be obvious by the exit criteria collection if the review is required.
Mistake #4 - Scoping without a GOLIVE date
It is possible to scope a release without a GOLIVE date but then we would need to have a set complexity/story point output from development and a set release frequency. Otherwise there are too many variables to start scoping: if we don't know how much build is possible during what period then we cannot finalise the scope of anything. And the longer we keep a release scope open the more release applicants pop-up wanting to go live. Certainly you can ask, how would that be possible to have a set release frequency (ex: monthly) without having a set GOLIVE date? And you would be right, if our release frequency is set we already have a set GOLIVE date. (Though parallel releases could tolerate some flexibility in golive dates per release.)