Managing Requirements in an Agile Environment
In many ways, the manner of capturing requirements in an Agile project management environment is similar to a “waterfall,” or traditional project management environment - numerous meetings with subject matter experts, end users, walkthrough / documenting the current business workflow, creating mockups, etc. However, Agile and traditional project management approaches contrast in how requirements are managed over time.
Some fundamental differences in managing requirements include:
| Traditional Requirements Management | Agile Requirements Management |
|---|---|
| In a “waterfall” project management environment, the approach is to capture and define all of the end-state requirements upfront. | In an Agile project management environment, while high-level requirements are also captured upfront, it is understood that requirements may evolve over the course of the effort. |
| Requirements are documented in a business requirements document (BRD) or business specifications document (BSD) for the purpose of designing the end state of a product. | The effort begins with a high-level scope agreement where initial business requirements are translated into user stories. Those user stories specify the needs of the product based on the information at the time given. |
| The goal is to understand the “as-is” state of the existing product or the business gaps that define the lack, so that the “to-be” state of the desired product can be defined. | The goal is no longer focused on eliciting the “as-is” in order to the define the “to-be,” but to clarify and ensure understanding of the business need for all users. |
| By defining the end-state of the application from the beginning, there is little room for change once development begins. | As more information becomes known over time, the team is better able to adjust and make changes accordingly. |
Managing requirements in an Agile project management environment is to think through the full life cycle of the requirement; to consider the full user experience and even beyond the defined stakeholders. Business requirements should be broken down in such a way that supports iterative development and enables flexibility to respond to potential changes as each increment is delivered and reviewed by business users and / or customers.
Further, requirements should produce strong, testable user stories that are clarified and reviewed often with the customer, end users, and development. User stories should promote a consistent conversation with the team that not only strengthens understanding of the business need, but results in more informed estimation and prioritization. As both the business users and the development team are engaged throughout the project, it builds trust and encourages collaboration across the board. Finally, it ensures faster, better delivery of requirements that truly convey and meet the business need.