Agile & Traditional Requirements (5 Differences)


Let’s start with a brief overview of what is considered to be an Agile Requirement.

  • They are defined iteratively and incrementally
  • They are not part of a formal sign-off process
  • They are defined via conversations between the team and users
  • BA work is done iteratively rather than all up-front
  • There is more emphasis placed on verbal and visual communications versus documents

It is all well and good having this definition but this leads to the question, how do they differ from traditional methodologies? Keep reading to find out the 5 main ways requirements are different on an Agile project.


1. Requirements are expressed as User Stories

A User Story is a requirement, written from the perspective of an end-user goal; As a I want so that . This format helps to bring out the business and user needs. They are popular because:

  • Focuses on the viewpoint of a role that will use or be impacted by the solution
  • Defines the requirement in language that has meaning for that role
  • Helps to clarify the true reason for the requirement
  • Helps define high-level requirements without going into low level detail too early
  • Defines the business values for requirements


2. INVEST model for user stories

As you have seen AgileBA® requirements are written as User Stories, this means they are often written differently than non-agile methodologies. Bill Wake sets out the standard way to write a User Story with his I.N.V.E.S.T model. Find out more here from the expert himself.  Stories should be:

  • Independent: User Stories should be as independent as possible from other stories. If user stories are tightly dependent, consider combining them into a single user story.
  • Negotiable: User Stories are not a contract. They are ‘placeholders’ for features which the team will discuss and clarify near to the time of development.
  • Valuable: User Stories should represent features which are of clear business value to the user or owner of the solution and should be written in their language. They should be features, not tasks.
  • Estimable: User Stories need to be clear enough to estimate, without being too detailed.
  • Small: User Stories should be small enough to be estimated.
  • Testable: User Stories should be testable.


3. Expect and welcome change

With the Agile approach to requirements you first clarify the project objective and Business Case in order to create a very high level set of requirements. Detailed requirement definition is left to just before it is needed.

This means that changes are accepted and adapted depending on the project needs. Defining a full set of requirements too early in a project can often be more of a restriction as it limits your process. It’s impossible to know all of the detail from the start, you need to learn as you go.


4. Basis of a conversation rather than weighty deliverables

The way in which requirements evolve through the DSDM® lifecycle means that they start out as a small conversation type document that is not set in stone. They form the base for a more detailed requirement, as the project progresses.

This means that a conversation about the requirements is always happening, they are always at the forefront of the minds and constantly kept up to date. A key deliverable that drives much of the delivery on an Agile project is the Prioritised Requirements list (PRL). This is a very similar the similar to the Product Backlog in SCRUM.


5. Prioritisation is vital

The level of detail in the requirements alters throughout the lifecycle. As requirements become more specific, estimates and priorities have to become more precise and therefore prioritisation becomes far more important.

A Prioritised Requirements List needs to be developed and confirmed to make sure the ‘Must Have’ requirements are completed within a Timebox.



Our easy to follow online course which provides a structured overview of business analysis and what it takes to become an excellent Business Analyst. Perfect for Entry Level BAs, Career Changers or for anyone interested in Business Analysis. It’s also great refresher course for Experienced BAs.

Ba Simplified