How many times do you think Business Analysts are asked this question throughout their career? It is commonly known as scope creep, and typically occurs when the original success criteria for a given feature is not clearly defined by the stakeholders. As a Business Analyst, scope creep can be very challenging to overcome during feature development. You have to really analyze what is being requested and compare it to the original business requirements to deem if it is truly worthy to ‘add’ to a feature. Even if it is deemed worthy to add, then you have to evaluate the impacts to development and testing.
When I find myself in this scenario, I ask myself:
- Why is this add-on being requested? What additional challenge will it solve (if any)?
- Which persona would benefit from this add-on, and how?
- Is it just something a stakeholder has noted as a “nice to have”?
- Or is this a missed requirement from the initial discovery meeting?
- Is the modification a key component of functionality or could it be added in the future?
- Where is engineering in the development cycle?
- How much additional development/testing is required? What is the overall risk and is it significant?
I have found that when you are faced with this dilemma that it is always best to try to understand why a modification, simple or not, is being requested for a feature. Could I, as the requirements owner, have asked better questions during the initial product discovery/planning? I have also found that even if the modification is a “good idea” that it does not necessarily mean that it should be done. As a Business Analyst, you have to know when to put your foot down and say no (politely and professionally) to the suggested add-ons that derail meetings and final requirement review sessions.
Features are given engineering estimates for a reason. Each and every add-on may have significant impacts or risks and thus, scope creep ensues reducing the speed to value for the person on the other side of your technology. As product professionals, we all need to be aware of scope creep and have the ability to identify it up front before it gets out of hand. A Business Analyst should be conservative and strategic with a solution, while ensuring that it meets the defined success criteria and that value is being maximized. Obtaining sign-off from stakeholders, after a final solution is agreed upon, should always be best practice so that scope creep can be prevented throughout the development cycle.
Now, if you have development experience then you are probably saying, “but this will result in multiple phases of a feature and never reaching completion.” That is only true if the success criteria, for a given feature, is not defined from the very beginning. A Business Analyst has to make confident decisions, deem items out of scope as necessary, and move forward. No one ever said being a Business Analyst was easy. It is a balancing act to get the feature just right—not too much and not too little. The idea though, is to do that balancing upfront so that scope creep does not make an appearance late in the game.
So the next time any of you Business Analysts are asked to “add just one more thing” carefully evaluate the request and its impacts. If it does not align with the success criteria defined then push it to be evaluated in a future cycle, and know that it is okay to just say no to scope creep.