Business Requirements

Home » Product Design and Management » Business Requirements
Home » Product Design and Management » Business Requirements

An Agile approach to Business Requirements.

Business requirements define of the business need that a project must meet and how we will measure successful delivery.

Agile, no less than other approaches, needs business requirements. The key differences in Agile are the level these requirements are generated at, when they are gathered in the project lifecycle and the level of customer feedback incorporated after the start of the project.

Timing of requirements

Gathering business requirements can absorb large amounts of time and analytical resources. If circumstances change while the requirements are being gathered or afterwards it can lead to significant wasted effort. 


Market dynamics shift, businesses are re-structured, new systems and processes are implemented, new regulations and risk controls become relevant, key personnel leave and customers can change their minds. Because of these changes, the business requirements can move substantially. 


Consequently, defining all requirements up-front will lead to either waste due to change or a project that does not deliver the expected business value.

Depth of detail within traditional business requirements.

To avoid waste caused by changing requirements and eventual acceptance by the business, many traditional approaches will extend business requirements to also define functional requirements and detailed elements of scope. The underlying rationale for this approach is that if the business agrees to all of the details up-front, it cannot object to the final delivery.

There are four issues with this approach:


  1. If the external business context changes the business needs can change rendering the detailed requirements useless 
  2. Spending more time on highly detailed requirements leads to significantly more waste if business needs change 
  3. Even detailed requirements may not create a shared understanding between the business team writing the requirements and the team delivering them. Those writing the requirements may not understand what they are ‘getting’ until they see it 
  4. Time taken to define all requirements significantly delays the start of the project execution and therefore delays speed to market 

Customer Feedback

Traditional approaches to creating business requirements restrict customer feedback to the beginning of the project. As noted previously, this is asking the business to provide feedback on a result they have not seen and may not be able conceptualise.  


Feedback after delivery is usually considered “scope-creep” and/or may require change requests with additional funding. Although this controls expenditure from a project perspective it simply shifts the costs of non-delivery or additional funding back onto the business.

An Agile approach to Business Requirements.

The Agile approach is to:

Define the business need and measures of success.

Commence refining of the first stage into smaller scale business needs that are meaningful to the business and can be delivered in a short timeframe.

Break the business need into a high-level roadmap.

Define what is needed, not how it will be accomplished

Start execution as soon as there are enough smaller scale needs defined to work on.

Regularly show the ongoing work to the business so that it can give feedback to incorporate into the remainder of the project.

This approach means:


Development can start sooner  

The business can directly influence the outcome and value delivered