Versions Compared

Old Version 5

changes.mady.by.user David Backeberg (Unlicensed)

Saved on

compared with

New Version 6

changes.mady.by.user David Backeberg (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

R1147 is a requirement to resolve issues with customers adding comments to an RITM, and the fulfillment people performing the SCTASK never seeing those comments. The requirement is defect-free, and passed UAT twice. The original fix was envisioned as applying to just one particularly problematic set of customers, but Soren saw that it had benefits for the entire system. The team consensus seems to be that we want to remove this from the release and never apply this fix in the future. Because of this change to the release, and because of other changes to the release, I recommend cloning over PRE-PROD to remove R1147 from the release originally scheduled for April. R1147 can be safely disabled in TEST using the 6A method, and I recommend doing so.

What does this mean for the release originally scheduled for April

PRE-PROD: No matter what, we are not moving this release to PROD as originally planned in April. We will need to at the very least, clone over PRE-PROD, and re-apply the new release. However, the new release is not finalized yet. I don't think we should do the next release to PRE-PROD until we are code complete with any issues we may uncover with our more rigorous testing we have planned for TEST environment. I think we should leave PRE-PROD alone until we have finalized the release, even if that takes a few weeks.

TEST: I think we should try harder with the second UAT approval for R780. If we don't get it, I think we should leave R780 in the release, but apply an additional small update set to disable it until the time when we are comfortable releasing it. R780 cleared UAT once and has no defects. R812 has a minor defect, identified in the second UAT session. I think we should leave R812 in the release, apply the fix for R1031, and have the stakeholders verify the fix after it is blessed by our testers. For R1147, I personally feel we should postpone action until we discuss with Soren, who is the process owner for the Request module. The original scope was just to modify a single Catalog Item, and after explaining the Use Cases she suggested a more cohesive fix would be beneficial to everybody. While the original fix was suggested by one person with a particularly acute issue, the fix can help many people not lose issues between the cracks.