When it comes to Agile development, the fact that is to be kept in mind is that change is the only constant. Companies become dynamic because the requirements of users keep on changing. Although such changes may be value addition, as a business analyst one needs to make sure that it does not expose a project to falling off balance. Here is where the Business Analysts come in as they can be viewed as the compass of the ship; making sure that each shift does not cause the project to take the wrong path and the new requirements align with the existing system.
At the beginning of my career, I worked in Ellomed, a system of Electronic Health Records (EHR). The simple idea of assisting clinics and doctors with their appointments and schedules at first turned out to be much bigger. Agile being played, the requirements were evident to be changing at the very beginning. It was not about whether things would change but how to deal with these changes in a better way. The motive was to deliver a quality product at the end of the day.
Building a Solid Foundation
In ElloMed, the first move was to establish a non-negotiable basis, the features that would not be affected by anything.
This anchor made certain that the core will not shake in case of later additions of improvements or even new modules. By obtaining this base, we gained flexibility, but not stability through out the process.
Fact: In Agile projects, a solid base minimises the rework whereby core modules are not redesigned each time there is a requirement change. The whole point in agile is about flexibility to modify the system as per the frequent requirements.
Pharmacy Energizing
One of the biggest changes occurred when there was the integration of pharmacy. It appeared to be another feature at first sight. However, my study found out that there were more serious problems with the current pharmacy systems:
- Inventory was to be checked by manually checking the medicines and other items.
- Out of date products were not marked automatically that indicates lack of expiry management
- Interfaces were not user friendly and looked out dated.
In the case of BAs, the issue at hand was to transform a general request, such as make pharmacy easy to manage, into specific and practical requirements.
Our Approach:
- Gap Analysis- Uncovered inefficiencies in existing systems.
- Competitor Research- Research on tools available of strengths and weaknesses.
- User-Centered design- What pharmacists and staff really needed that can help in making the pharmacy management easier.
The Solution:
We introduced a full-fledged and user-friendly interface designed specifically for pharmacists- one that covered every loophole we had identified during analysis phase.
- Efficient expiry management with automatic alerts and red highlights for expired products
- Managed inventory and order controls that minimized effort and errors.
- An intuitive design that made day-to-day tasks quicker, simpler and far more efficient.
What seemed like a dramatic requirement shift didn’t create disruption because the foundation of ElloMed was already strong, this enhancement only elevated the system transforming it into a tool that was not just functional but genuinely easy and efficient for users.
How BAs Maintain the timelines of projects in case of requirements shifts
ElloMed showed that requirement changes do not necessarily cause consternation. BAs will be in a position to facilitate smooth transitions, with the correct practices that are considered from the very starting of the project.
Here’s how:
- Priorities: Segregate the requirements based on must-haves” vs “nice-to-haves” early on.
- Impact Assessment: This is categorized as an evaluation of the impact of a new change on existing modules before development commences in order to make sure that every new requirement aligns with the existing system and does not break the ongoing flow.
- Documentation: Have a clear record of all requirements, the reason behind its change and the person that authorized the change. This way we can track the record of frequent requirement change.
- Prototyping: Prototyping allows you to check the ideas first by using quick wireframes before starting to design and code them. This is one of the most time saving processes.
- Requirement Alignment: Frequent sprint reviews and requirement check-ins ensure that all are on track. Here, communication is the key to ensure that everyone on the team is on the same page of understanding.
Smart Tips for Agile BAs
The thing is that in Agile it is not only about the process but it is about the way of thinking. Handling dynamic requirements is like sailing in a changing wind; you cannot control the wind, but you can move the sails. A few tips that I found helpful are:
- Sort wheat and chaff apart → Figure out the must-have and nice-to-have list early in life.
- Keep the pulse alive → Have a living history of changes and business value.
- Big bites, small impact → Dividend large requirements into smaller deliverable units.
- Three heads are more than one → Rapidly converge to Three Amigos strategy (BA + Dev + QA).
- Trace back to purpose → It is always important to have changes being linked to the larger business objective.
Lessons from Ellomed
Ellomed was not only a project but more of an Agile classroom. Here’s what it taught me:
- The magic ingredients are patience → Agile succeeds where you allow flexibility of its time. The presence of strong roots, the constant growth, therefore, results in the minimization of chaos in case of the change in requirements.
- Clarity is power → Divide the amorphous thoughts into clear, testable, implementable solutions.
- Make lemons into lemonade → Requirement shifts but the embraced requirement shifts can make the product even stronger.
Conclusion
Requirement changes are not a roadblock in Agile, rather a detour that can get to the destination provided that they are managed properly. It is the way the wheel is turned by BAs.
Business Analysts are the stabilizers of the ship- when there are alterations in directions they are the people who see to it that the project does not head in the wrong direction.
The ideal example is Ellomed: initially a functional scheduling program, it has developed into a highly reputed EHR that has smart pharmacy integration. This was because requirements changes were not feared but leveraged.
As it is said, the strongest or the smartest do not survive, but the most adaptable one. Having the appropriate BA practices such as building the foundation, prioritization and flexibility, the projects do not only remain on track but also emerge as solutions that count.
Facing shifting requirements in your Agile projects? Ellocent Labs expert Business Analysts specialize in impact assessments, prioritization frameworks, and prototyping strategies to keep your projects on track. Contact us today to ensure seamless project delivery.
Leave a Reply