How to write a business requirements document in Agile

How a BRD sets expectations

A BRD describes the business purpose for a project. It defines how to produce the product, including its objective, how it works and the client's intended use. With a BRD, a business can assess potential cost factors and constraints, and a timeline or schedule for the software project. It also outlines the expectations and required deliverables for individual projects and sets benchmarks that both quantify and qualify a project's success.

BRDs can take on various structures. Product development teams can write a BRD from scratch or use an example template and tinker with it to meet their needs. However, regardless of its origins, an effective BRD typically includes 10 standard informational components:

1. An executive summary or other overview of the project.
2. A list of success benchmarks and project objectives.
3. An explanation of the project's scope (what definitely will and won't be included).
4. Identification of major project stakeholders.
5. Essential business requirements and objectives.
6. Intended scope of the final product or service.
7. Functional and non-functional system requirements (optional).
8. Potential project constraints and cost-benefit analyses.
9. A reference for quality control measures.
10. A schedule of project timeframes and deadlines.

Click here for a downloadable BRD template.

How to use BRDs in Agile development

In Agile, defined product features are often included as part of the project epic, which is a large user story that is eventually broken down into a series of project tasks and subtasks. These epics often incorporate a large portion of the information found in a BRD, which project managers and product owners can work together on to translate into a scheduled series of project tasks or a detailed product roadmap. Teams can also use this information to refine user stories and provide better descriptions of feature needs and scope. This is where developers finally attain the detailed functional requirements they'll need to fulfill the business requirements.

The user story format briefly describes the value a target end user or customer is looking for, but in a very straightforward manner. An example of this within a BRD might resemble something like: "I am a <insert type of user/role/customer>, and I need <this product/capability/service> in order to <insert reason/goal/benefit>."

User stories can also include acceptance criteria, which qualifies essential functionality and necessary capabilities that the project will need to address. This also provides the benchmark developers can use to know if they've delivered on that user story or not, such as performance of existing products that were considered successful. Some groups go even further, breaking down user stories into sub-tasks that focus on individual system components. For example, a user story may detail the work a development team must perform on an application's UI, back end and database components as part of the requirements for meeting customer needs.

In Agile development scenarios, a team might use the BRD to create epics that draw relationships between high-level product features and back-end development tasks via a series of parent/child relationships. Project managers and owners can integrate user stories within their own parent tasks, with all relevant child development tasks connecting back to the overarching user story. This type of workflow illustration can help project managers accurately track progress at each stage of a project, as well as backtrack a project in response to required changes or shifted priorities.

How to react to business requirement changes

Customers can make requests for changes (RFCs) and vendors can accordingly write and approve revised business requirements. However, if not properly managed, RFCs can induce additional costs and increased timelines for development projects. Managing these changes is different in Agile scenarios than in non-Agile development scenarios.

For instance, development teams that follow a Waterfall model often place BRDs in the hands of a designated change control board. This body has sole authorization to preapprove requested changes and is also in charge of confirming that the approved changes were made in accordance with required specifications.

Changes in Agile, meanwhile, take the form of either additional project epics or user stories that change in tandem with the scope of the RFC. Changes move through the following process:

1. The product owner forms a control board that includes product development team members.
2. Client, business-side and software team stakeholders negotiate an agreement regarding feature changes and additions.
3. The team creates a series of new user stories that the product owner can use to help those developers reprioritize both new and backlogged project tasks.
4. Development team reviews user stories in backlog grooming sessions and restructures the project schedules and workflows as needed.

How to measure completion of business requirements

Agile teams measure success at multiple levels of the product development process, from high-level planning to frontline releases. However, each layer does require a different perspective and scope by which to accurately judge a project's success, particularly if using a BRD to do so. There are three layers that are particularly important for Agile development teams to know how to navigate:

• Release level. A product owner must continuously calculate tradeoffs in project scope, timelines, budget and quality as streams of important cost, revenue and budget information arrive throughout the stages of a product's development. Ultimately, Agile teams can measure success at this level by the number of working product features that were delivered on time per the BRD's timeline info.
• Task level. To deliver product features on time, an Agile project team must simultaneously perform schedule-bound development tasks, manage user stories and perform continuous acceptance testing on each feature. At the task level, teams can measure success based on how many of the unit tests performed on code verify that it meets the threshold necessary for a formal commit.
• User story level. Agile teams often use acceptance criteria as a benchmark to determine if they satisfied requirements for the feature. When developers meet the criteria for all the user stories within the project, they can then perform user acceptance testing on epics or directly on the features.