_ Agile Business Requirements – 3 basic attributes

Adrian Sita

Agile Software Development
—
October 8, 2019

3min

What are the three main characteristics of Agile Business Requirements?

1. Atomic (Agile Business Requirements)

This is the key attribute a requirement must-have.

Think to an atom like it is one of the smallest parts of an undivided matter. The requirement should be in its smallest indivisible form, containing the capability requested by the stakeholder – not letting a place of interpretation.

If it’s the last piece that the team cannot divide it, then that is the hint for ‘Atomic’ attribute.

Each individual requirement within the set should relate to one and only one thing. Or, put another way, each requirement should be atomic. This is of relevance to detailed textural requirement artefacts.

For example, declarative requirement statements (“The system shall…” or “A user can…” – in terms of User Stories) or textural business rules. (source)

2. Unambiguous

Prepare for the ‘just enough’ information but be sure that there is “no pathway to the right or left” as I like to call it.

In this way, every team member or any stakeholder understands what the Agile Product Owner or Agile Business Analyst wants to achieve – sometimes there is only one person for both roles which is an anti-pattern.

Why is this important?

In every business environment one of the essential characteristic is transparency is at the core of being Agile.

From increasing employee retention to boosting sales, transparency can do a lot for your small business’s reputation and success.

If your business is straightforward, you may see a rise in your customer base. One study found that 94% of consumers would be loyal to a transparent brand. (Forbes)

3. Testable

The Agile Business Analyst should write tests together with qualified engineers to ensure that the system is running, having the right parameters at the right value.

In this way, everyone who comes into contact with the requirement understands its purpose and how a person who makes the system verification to achieve the set goal.

According to this article, to be testable, requirements should be precise, and unambiguous.

Some words can make a requirement untestable:

some adjectives: robust, safe, accurate, effective, expandable, flexible, maintainable, reliable, user-friendly, adequate
some adverbs and adverbial phrases: quickly, safely, in a timely manner
non-specific words or acronyms: etc., and/or

Bonus: Necessary. Is it really needed?

Are you as an Agile Product Owner or an Agile Business Analyst sure that your client really needs it? Is the best way to describe it like this? In the same time, is it efficient to treat it like this?

If you ask any stakeholder, every requirement will probably be “necessary”.

The best way to verify that requirements are necessary is to ‘take the light’ (as I like to call it) from real customers and try to understand their ‘why’…. even if they say that it’s necessary still can have an inexplicable ‘why’.

Find the way to test the hypotheses by making the stakeholders to pay for the feature. As the payment is happening than you know for sure, that is necessary!

Some (final) thoughts

What’s the downside of not having well written agile business requirements? Simple said: inefficiency, which can translate into losing time/money or even going out of business because of not achieving the settled goals.

This article is part of a bigger topic called: Agile Software Development