Dealing with changes in requirements!

This happens to everyone irrespective of the SDLC phase - mostly in the late development phase for business/customer’s benefit…

General scenarios when one ends up in this situation :

You are in the middle of validating a User Story, you find some gaps considering User’s behaviour for the functionality which are leading to bugs, you check with BA/PO and they change the requirement.

OR You just signed off the story. It’s about to be released as an update. And your Product owner comes up with the changes in requirements - could be due to content, UI/UX, or legal.

Sounds like a daily thing right? It is so much of rework starting form test case design till sign off. Plus the release dates are unmoved!

How do you deal with it? And how do you avoid this from happening again and again?

How to avoid such changes: Well, most of the times, it’s unavoidable!

Changes are part of a successful Project. The team learns from the experience though.

But one should have control on changing requirements while at the same time being flexible in requirements.

Business, legal, content, beta testing - these are the few things which may lead to changes in requirements which we can’t avoid addressing at a priority.

When you are asked to introduce a change before go-live :

See if this change can be taken in the next release and doesn’t harm user/business. Sometimes, some changes don’t add much value, but the act of introducing the change may have an undesired impact on time and budget without much of a benefit to the business.
Avoid the change if the impact is a big one in case of time required to build and test and sign off considering no harm to business/user.

Project management practices during development :

Give much more attention during the Planning phase. Plan for the Planning phase to be more of brainstorming with the earlier experience of change, and think more about customer and business. For any little doubt, BA/PO can go to business and get queries clarified or suggest better ideas. This way, changes are identified in the planning phase itself instead of late during the development phase.
Have all the team in Planning/ requirement specification phase including QA.
Have OKR specified. Convert them to Goals, hypothesis and work on them before pulling them into Sprints.
Have a business review at the end of every sprint for the sprint deliverables. So, if there has to be any change, it’s just that sprint’s work addition/ modification.

Changes happen… Deal with it… So let’s see how to maintain the quality irrespective of changing requirements :

Analyse the impact, see the benefits and the priority to implement it.
Check if it helps meet any of the OKR (Objective Key Results).
Analyse the regression required. Sometimes, the change may be just a one-liner in code but may end up in full rigorous regression.
Analyse how to fit in timelines or if timelines can be moved.
Implement the changes locally and check what all unit test cases and automated test cases break to get to the impact analysis quicker and right.
Implement, test, beta test and release!

Learnings to be taken if the reasons were any of the below:

If the requirement was missed - communication to be improved and be made more effective between BA/PO/customer & Team
If a bug was found by the customer - Peer reviews and BA reviews of the demo to be more stringent
Actual requirement change by the customer in Beta testing - what customer had originally told the team to implement, and would now like a change. - Try to get the Beta test done by the end of every Sprint or two for the customer to try and understand the new solution earlier.
Legal laws/ rule changes - see the date to have the changes live and whether the change can be taken to the next sprint or it’s a critical change that needs to go live now.
Business/user’s benefit - analyse the value. If it’s of smaller value, you can deal with it in the next sprint.
Changes in external conditions - gain an understanding of these kinds of situations for future planning.
Increased knowledge of what exactly the customer wants - plan a demo to the customer by the end of each sprint starting from the early days, to help gain understanding. Keep these demos going regularly.

Changes happen… Learn to deal with it!!