BANTER Business Analysts on Business Analysis

04/10/2016

5 Differences between Agile & Traditional Requirements

In this post we will have a more detailed look at being on an Agile project or being an Agile BA, starting with Agile Requirements.

First 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.

Check out our post 4 Similarities between Agile & Traditional Requirements to see the similarities.
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:

five-720-x-340

1. Requirements are expressed as User Stories

  • 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.

 

If you have other examples we would love to hear them.   You can post them up in the comments section below.

AgileBA® Training Courses

We currently have AgileBA® Foundation Level training courses scheduled for Edinburgh and Dublin.  Prices and details can be found here: AgileBA® Courses 2016

Want us to come to you?

We can also deliver our AgileBA® training courses at a location that suits you.  Contact us today at info@be-positive.co.uk to discuss your training needs.

APMG AgileBA Logo

Be Positive Newsletter
Worried you might miss one of our posts? Sign up to our newsletter and receive a regular roundup of all posts we published. Be kept up to date with all the latest industry knowledge and training courses.
Be Positive logo
Contact us now to discuss how we can help Enhance your Business Analysis capability.
Easter Dalry House, 3 Distillery Lane, Haymarket, Edinburgh, EH11 2BD
Google + | Site Map | LinkedIn | Twitter | Privacy Policy | Terms & conditions
© Be Positive 2018