Business analysis is the process of identifying problems, business needs and, consequently, recommending viable solutions to meet them. Part of this is the elicitation, documentation, and management of stakeholder requirements to meet business objectives. Business Analysts (BA) should also be able to facilitate the successful development of a product. BAs should act as an effective go-between stakeholders and developers to make sure that what’s envisioned will be delivered. There are two main approaches to software business analysis – Waterfall, also known as the “big-bang approach”, and Agile, commonly called the “iterative approach”.
Waterfall vs Agile, which one is for you
Waterfall business analysis is deeply rooted from the manufacturing and construction industry’s business analysis strategy. Here, architects and engineers plan everything at the start, have the plan locked-down, and eventually have the plan accepted by clients before construction begins. During implementation, the project manager makes sure that nobody will divert from the requirements, hence making engineers resist all changes, preventing the client from injecting new ideas. Also, in a big-bang business analysis, the success of the project is mainly defined by its capability to meet all baselines: schedule, cost, budget and scope.
On the other side of the spectrum is the Agile methodology. Agile rose from the unique nature of software development projects. Unlike buildings, roads, and bridges, software requirements cannot be identified in just one sitting. This is mainly due to the changing business requirements that are dictated by fluctuating business priorities necessary to stay competitive in the market and the highly volatile preferences of global consumers.
The difference between Waterfall and Agile business analysis
According to this most recent study on the state of Agile, approximately 60% of companies in the United States shifted to using Agile while 40% stayed true to Waterfall. Whatever the business analysis strategy may be, it is important for the BA to understand waterfall vs agile business analysis so that they can be properly guided with any project approach.
Waterfall vs Agile Requirements Gathering
The requirements gathering method varies a lot if you are coming from a Waterfall tradition. In waterfall, BAs are told to gather all requirements at the start, even though there is very little information known about the project. However, this approach bears a very high risk. The Cone of Uncertainty states that more details about the requirements will emerge during the mid to late part of the project. Hence, it is inevitable that the requirements will change. This reality of software development life-cycle is embraced by Agile. As such, during the requirements gathering stage, the business analysis strategy only revolves around elaborating features that can be developed for the next 30 days. All requirements that have not yet been prioritized by the Product Owner is left untouched in the Product Backlog until the team is ready to work on it.
Waterfall vs Agile Requirements Documentation
Due to the big-bang approach that Waterfall is taking, requirements documentation is done in a very formal way. Here, the BA will write the whole document in Word and have it routed for sign-off. In Agile, BAs can leverage business analysis tools that will allow them to progressively elaborate their requirements as they move along the project. Business analysis tools such as Blueprint, eDevTech, IBM, Jama, and Polarion are the top cloud-based solutions that can be leveraged to make requirements elaboration leaner and faster. On the other side of the coin, it is worthy to note that Waterfall’s very detailed and formal documentation process may fit certain organizations that must comply with rigorous standards, particularly those of the banking and healthcare industries. Annual attestation activities require them to have these formal documents that seem to be more in line with the Waterfall methodology.
Waterfall vs Agile Requirements Baseline and Change Management
The concept of creating a requirements baseline is inherent in the Waterfall methodology. Here, the business analysis strategy involves locking down all specifications as stated in the document which in turn is used by the project manager as a basis to measure project success. Any requirements that are not stated in the baseline will be rejected and must undergo a formal change request process. This process, although it protects the project from scope creep and negative cost overrun, doesn’t necessarily guarantee project success.
The concept of business value is very important in the Agile methodology. Here, the measurement of success doesn’t lie in maintaining the baselines and preventing any change requests. Rather, success lies in a working software that maximizes business value. Business value can mean performance improvement, increase in user engagement, sign-ups, or meeting objectives as defined in the business case. As such, when an Agile project faces requirements changes, instead of resisting it, they do requirements trade-offs. This is one of the business analysis practices that the Product Owner should do to deprioritize requirements that are not MUST Haves and replace them with more important features that will maximize the value of the increment.
Requirements in software development projects regularly evolve unlike in other industries which a big requirement upfront (BRUF) is the norm. In choosing a project management method, especially in software development, it is best to make a reality check. Do you think requirements that you have identified during planning will not change? Based on the company’s historical data of completed projects, you can easily find the answer. From here, take the courage to make the right decision and discuss it with management.
