As Business Analysts we traditionally gather project requirements early in the process. We hold focus groups, we interview subject matter experts, we gather all we think we need for a project and then create the Business Requirements Documentation, get the green light, and hand it off to the developers.
Risk is high during this time, as we do not get valuable feedback until our client sees functioning software. This software may or may not align with what their vision was in previous months. So much could have changed in the time between requirements sign off and the demo of functioning software to our clients. The Business could have changed. Management could have changed. Software or processes could have changed. Technology will definitely change. We run a higher risk of not delivering what the business or client requires.
This is where Agile comes in – we provide feedback early and often during the development process. We also include client input when creating the Requirements (user stories) and show them working software piece by piece, as we develop. This reduces the risk and allows for feedback early and often so that we can be sure that what we produce is in alignment with what our clients require. If technology changes along the way, we change with it. If management changes along the way, we work with new management to ensure that we are still aligned during development. We can produce a higher quality product with the feedback and interaction along the way with Agile. Isn’t that what we wanted all along?
About the Author
Caprice White is a seasoned Business Systems Analyst with the BC Liquor Distribution Branch.
Caprice was the Analyst for the BCLDB’s first and subsequent Agile Projects. She strives to educate other Analysts on how to build credibility and find their voice to realize their fullest potential, creating value within their personal and professional lives.
Powered by Facebook Comments