GSA/christopher

---
title: Managing Requirements in an Agile Environment
category: Agile
audiences:
  - Developers
  - Designers
  - Project Managers
---

<style>
  table {
    width: 100%;
    table-layout: fixed;
  }
</style>

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]({{ site.baseurl }}/guides/effective_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]({{ site.baseurl }}/guides/estimation_and_storypointing/) and prioritization. As both the business users and the development team are engaged throughout the project, it builds trust and encourages [collaboration]({{ site.baseurl }}/guides/Business_and_IT_Collaboration/) across the board. Finally, it ensures faster, better delivery of requirements that truly convey and meet the business need.