While less than one percent of IT departments even heard about Agile in 2000, Gartner and Forrester statistics indicate that 60-80 percent of software development teams now use Agile as their primary method for creating software. We echoed similar sentiments in our blog “Agile development methodology is not a choice anymore, it has become the only way to continuously improve”.

Image Source: http://blog.soshace.com/wp-content/uploads/2016/08/agilenewera.png

To have a successful project delivery using the Agile Software Development Methodology, gathering project requirements is the first critical step. In a traditional software development approach, all the requirements are gathered, assessed and estimated at the very beginning of the project. If finalized and approved, it is signed off by stakeholders, which means that it cannot be changed any further. This approach does not involve any participation from developers, testers or team and the assumption is that all the requirements can be forecasted, analyzed and gathered at the very beginning. Any change in the requirements is considered to be an exception, and is dealt with as it occurs without any prior consideration in terms of time, complexity and cost.

In our blog titled Effective Requirement Gathering For Agile Success, we covered the 4 key components of requirements gathering. These components include developing a vision for the high-level details, brainstorming for features of requirements, breaking down of features into user story, and defining detailed requirements.

One of the key requirements of the requirements gathering phase in Agile is to break down the scope of work. It is broken into disparate buckets of work wherein the largest buckets are called Epics (defining the major items of development). The Epics are further divided into smaller pieces of work called Stories, which are further split into individual tasks. While planning the project under Agile, one has to carefully consider the dependencies between each of the Epics and Stories. The tasks are then prioritized depending on the business demands. Finally, the Epics and Stories are slotted into blocks of development time, called Sprints, for development.

The requirements gathering phase, irrespective of the methodology, will never capture all the required details that become clearer in the development phase. It is recommended to capture as many details from inception so that there is less rework, more preparedness and more clarity. The information that is collected during the requirements phase becomes a critical framework to build the requirements gathering document (within a given sprint).

One of the key aspects of the requirements gathering phase is to document all the functionalities of the end product after a discussion with the business stakeholders. Another key discussion for the team is to consider out of scope functionalities, document the same and take a sign-off from the client (records of discussion with the client should be documented as well). If there is something from out-scope functionality that needs to be added, it can be discussed during the detailed requirements gathering phase. Being able to quickly point toward details from that previously made decision can save the project from a time-wasting digression. It is imperative to refer to prior decisions and streamline conversations and place the team back on track to complete the requirements-gathering process.

When working with offshore teams, requirements (gathered in a day) can be developed by the offshore team within a night. The off-shore team can be used for defect management and they can perform bug-fixes to improve the productivity of the team. Implementing a continuous cycle of work with offshore resources is attainable, but only with active involvement by management and constant communication among all resources.

At ISHIR, we too follow a streamlined process to ensure a smooth and complete requirements gathering phase in all our software projects using the agile development methodology. You can contact us to know the details.