Remember that scope affects planning and resource allocation for the release. It also affects how the TSC evaluates milestone progress and GO/NOGO decisions. For example, the component impact table documents what components will be impacted by the defined scope of the requirement. If your scope includes work that you won't do until subsequent releases, then the component impact table may imply allocation of resources that isn't necessary.
Also, if your defined scope is broader than what you intend to complete in the release, then it confuses TSC evaluation of your progress at milestones. Perhaps a good compromise would be to include two parts in the requirement description. The first part would document the overall scope of the requirement, while the second part would document the scope that you intend to complete for the current release. David On Wed, Dec 2, 2020 at 10:21 AM Rajewski Łukasz - Hurt < [email protected]> wrote: > So we mix here scope for release with the scope of the entire requirement > what is not the same. If the requirements can be defined for many releases > the scope for each release is a part of the entire one. Otherwise what we > mean by continuation of requirements by design? There is no such option > then and you consider only continuation for reqs that have some leftovers > but the original plan was to deliver them in one release. > > > > So do we really let requirements to be split into many releases by design? > I have an impression that no because nobody plans non-intentional delays in > the implementation by design. > > > > Regards, > > > > [image: Logo Orange] > > *Łukasz Rajewski*, R&D Expert > Orange Labs Poland, Advanced Network Solutions Agency > *Mob.: +48 519 310 854* > Orange Polska, Obrzeżna 7, 02-691 Warsaw > www.orange.pl > > *From:* David McBride <[email protected]> > *Sent:* Wednesday, December 2, 2020 6:51 PM > *To:* Rajewski Łukasz - Hurt <[email protected]> > *Cc:* [email protected]; onap-release <[email protected]>; > [email protected]; Kenny Paul <[email protected]> > *Subject:* Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ from > one release to the next #guilin #honolulu > > > > I respectfully disagree. > > > > It's fine to plan implementation of a requirement over multiple releases. > Nothing in this process contradicts that. However, the scope defined in the > Jira issue, should be the scope that you expect to complete *for that > release*, and not the entire requirement. > > > > David > > > > On Wed, Dec 2, 2020 at 9:45 AM Lukasz Rajewski via lists.onap.org > <[email protected]> wrote: > > Hi, > > > > one major remark. I believe this is wrong assumption that REQ by „design” > must be completed in one release. If feature is big and releases are more > frequent it is impossible to deliver bigger changes in one release. In > consequence, such feature by default must be split into several consecutive > releases and setting the scope status “reduced scope” is wrong. > > > > Regards, > > > > [image: Logo Orange] > > *Łukasz Rajewski*, R&D Expert > Orange Labs Poland, Advanced Network Solutions Agency > *Mob.: +48 519 310 854* > Orange Polska, Obrzeżna 7, 02-691 Warsaw > www.orange.pl > > > > *From:* [email protected] <[email protected]> *On Behalf Of *David > McBride > *Sent:* Wednesday, December 2, 2020 5:58 PM > *To:* onap-release <[email protected]>; > [email protected] > *Cc:* onap-tsc <[email protected]>; Kenny Paul < > [email protected]> > *Subject:* [onap-tsc] Continuing a REQ from one release to the next > #guilin #honolulu > > > > Team, > > > > I've gotten some questions about continuing a requirement from one release > to the next. So, for example, from Guilin to Honolulu. > > > > In order to track history, we decided that it would be better to create a > new issue, rather than change the "fixversion" field on the original > field. That way, the history of the scorecards, tsc approvals, scope, etc. > does not get reset. > > > > Process: > > Current Issue: > > 1. Add a comment: > > > - What was completed > - What remains to be done > - Assert that the requirement will be continued in the next release > > > 1. Change the "scope status" to "reduced scope" > 2. Update the Jira status as "Done" > > New Issue > > 1. Create a new issue with identical summary as the previous issue. > 2. Set fixversion to the target release version (e.g., Honolulu > Release). > 3. In the "Issue Links" field, add a link to the previous issue. > 4. Add a comment indicating that this issue is a continuation of a > previous issue (add Jira reference) > > Please let me know if you have any questions. > > > > David > > > > -- > > *David McBride* > > Release Manager > > Linux Foundation Networking (LFN) > > Mobile: +1.805.276.8018 > > Email: [email protected] > > IRC: dmcbride > > > > > > > -- > > *David McBride* > > Release Manager > > Linux Foundation Networking (LFN) > > Mobile: +1.805.276.8018 > > Email: [email protected] > > IRC: dmcbride > -- *David McBride* Release Manager Linux Foundation Networking (LFN) Mobile: +1.805.276.8018 Email: [email protected] IRC: dmcbride -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#7341): https://lists.onap.org/g/onap-tsc/message/7341 Mute This Topic: https://lists.onap.org/mt/78665769/21656 Mute #guilin:https://lists.onap.org/g/onap-tsc/mutehashtag/guilin Mute #honolulu:https://lists.onap.org/g/onap-tsc/mutehashtag/honolulu Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
