Coping with requirement descoping

Image: FreeDigitalPhotos.net

I am in the middle of a frantic ATG code push. The QA cycle (as usual) was a painfully short 2 days. Since the project is pretty large and was months in development, many areas of the UI were changed. Some of the changes were accepted by the QA and business team, but other changes were found to be too wonky to rollout live to thousands of agents. It was inevitable that the business side would request à la carte features from the overal design implemented to roll live (due to the short qa and hard deadline). Problems arise when removing (descoping) a rejected UI change which breaks other features because of dependencies.

I was able to deliever a rapid turnaround on descoping large functional sections of a code push. I did this by keeping a record of each file that was add/changed/removed for the project as well as correlated which business requirement(s) were the motivation behind the file's change.

Traceability saved the day.

I have not been as diciplined in the past with keeping track of changes for a project, let along keeping record of how the changes correlate to the busines requirements. Now, having done this, it is something that has helped me in the following specific ways:

1. fulfill all the documented requirements of the project,
2. quickly descope rejected code,
3. rapidly find and fix bugs found against requirements,
4. perform code reviews and explain the moving parts quickly,
5. provide detailed rollout plans for the changes,
6. merge in other changes into the project with ease

Not every project may be large enough to require record keeping like this. Keeping track of this stuff is boring but the benefits of doing it really make it worth the effort for me. (Just like documenting my knowledge has.)