Blog

    Contact

Requirements or User Stories?

Jan 10, 2020

User stories are talked about here (The Beauty of a User Story) and are commonly equated to requirements, you know, what we provide in the Business Requirements Document. So is it true, that user stories are the same as business requirements?

If you read the blog, you will hopefully recall that user stories:

... are simple, short descriptions of the desired functionality of a system, without any technical jargon ... a user story is written from the perspective of a specified user (role or class of user).

On the other hand, a requirement defines what a development teams need to build without giving the user’s perspective. The Product Owner or as has been traditionally done, a Business Analyst, may state the requirements, often in conjunction with technical leads.

Think of what are called the non-functional business requirements, and as an example, the security features or infrastructure requirements that the system needs. These will often not be customer facing.

Consider the two examples:

  • User story example: As a customer, I want to be able to reset my password so that I can access the system if I forget it.
  • Requirement example: The user must be able to reset their password once they requested a new password and have received a password reset email. The email should contain a unique link for resetting the password and that link should expire after 15 minutes. Valid passwords are detailed in the business rules section in the appendix and conform with Group security requirements.

Knowing this may not help you to write better user stories, but it will at least give you a bit of background on what user stories are and how writing these are different to what was documented as a requirement.

INVEST

INVEST is an acronym which encompasses the following ideas, and are necessary to make up a good user story:

  • Independent - if you reorder the item in the backlog it should make no difference
  • Negotiable - a user story is a discussion
  • Valuable - it solves a problem, the '.... so that ... ' part
  • Estimable - it needs to have a Return On Investment attributable
  • Small - small reduces ambiguity should be doable in one iteration
  • Testable - tests or acceptance criteria to prove it is 'Done'

Qualities of a Good Requirement

A good requirement is considered to have the following qualities and has some overlap with a good quality user story. I've put in brackets how it has that quality in common with a user story. 

  • Atomic - self-contained and capable of being understood independently of other requirements or designs. (Independent)
  • Complete - enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
  • Consistent - aligned with the identified needs of the stakeholders and not conflicting with other requirements. (negotiation should highlight consistency)
  • Concise - contains no extraneous and unnecessary content. (small)
  • Feasible - reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
  • Unambiguous - the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need. (small)
  • Testable - able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design. (Testable)
  • Prioritized - ranked, grouped, or negotiated in terms of importance and value against all other requirements. (Estimable, Valuable)
  • Understandable - represented using common terminology of the audience. (valuable)

What stands out is that the user story is not concerned with completeness or feasibility, This will be determined during discussion.


Scrum vs Kanban

(03/02/2020) First of all, let's have a recap of Agile software development. In very broad terms we have: A Product Owner (decides what to build) A Development Team builds it Users or Cus ... More →

The Agile Wild West

(02/01/2020) Agile is held up as the new way of doing things faster, and more in tune with the markets' demands. But it's not necessarily the pancea to solving the problem of creating software ... More →

Deadlines in an Agile Environment

(01/17/2020) Since Agile is flexible and adaptable, long-term deadlines don’t immediately fit into Agile and it was once said to me by a Product Owner that 'in agile there are no deadlines'. ... More →

Requirements or User Stories?

(01/10/2020) User stories are talked about here ( The Beauty of a User Story ) and are commonly equated to requirements, you know, what we provide in the Business Requirements Document. So is i ... More →

Documenting Agile Requirements

(12/28/2019) In a previous blog I discussed how to write a user story , and how to structure the product backlog . This is only part of how we manage requirements, and recall that I also rest ... More →

Scrum vs Kanban

(03/02/2020) First of all, let's have a recap of Agile software development. In very broad terms we have: A Product Owner (decides what to build) A Development Team builds it Users or Cus ... More →

The Agile Wild West

(02/01/2020) Agile is held up as the new way of doing things faster, and more in tune with the markets' demands. But it's not necessarily the pancea to solving the problem of creating software ... More →

Deadlines in an Agile Environment

(01/17/2020) Since Agile is flexible and adaptable, long-term deadlines don’t immediately fit into Agile and it was once said to me by a Product Owner that 'in agile there are no deadlines'. ... More →

Requirements or User Stories?

(01/10/2020) User stories are talked about here ( The Beauty of a User Story ) and are commonly equated to requirements, you know, what we provide in the Business Requirements Document. So is i ... More →

Documenting Agile Requirements

(12/28/2019) In a previous blog I discussed how to write a user story , and how to structure the product backlog . This is only part of how we manage requirements, and recall that I also rest ... More →

Shall we talk?

Lets have a conversation

If you would like to know more about how I've helped to transform some the world's biggest and well known businesses, across diverse industries in the United Kingdom, Singapore, and Hong Kong, then please drop me a line. Let's have a chat and I'll buy the coffee!

Multiple screens showing responsive web developement next to a hot drink for a meeting

Turn your idea into digital reality

Many of my clients requiring web design have been small or start up businesses and need a lot of guidance. I love these kind of projects as I feel I can be a part of a new and exciting business from the very beginning!

What do I call you?
Enter your email address
It would be nice to tell us why you are contacting us!
To prevent spam mail, enter the sum of the spam captcha
The spam captcha is: 4+8