Requirements Engineering in Agile: From Myth to Reality

Editor’s note: the following was written by a guest blogger. If you would like to contribute to the blog, please contact ellen@productschool.com

Requirements Engineering is a critical part of every software product development project, no matter what is your product management or product development approach. The quality of how you perform RE activities and their delivered outcomes directly impact the failure or success of your product management approach in the project.

But here the question is how can we apply the RE mindset, principles, techniques, and values in an Agile Product Management environment. Well, the most accurate and appropriate answer for this is making a BRIDGE between Requirements Engineering and Agile! In this article, you find out the myths and reality about Requirements Engineering in an Agile environment and how you can benefit from using RE in an Agile development environment by making a bridge between them.

You might also be interested in: Fundamental Principles of Requirements Engineering: The Key to Product Success

The Myth

gray horse under blue sky

There are many myths and misconceptions related to RE and Agile. In this section, I discussed common myths that maybe you are hearing on a daily basis in your teams and companies about RE and Agile. Let’s review them:

Myth 1: Upfront is not allowed in Agile Environments

Usually, even in the mature product teams, there is a myth that lies in the fact that if you want to be Agile, you have to forget any upfront activities. It is not true in a real Agile development environment. You have to do some upfront activities (i.e. product vision design) to build a compass for future development activities. Also, just like other activities such as coding and testing, you can form and use RE activities in Agile iterations.

Myth 2: RE is just a documentation activity

Many product people still consider RE just as a documentation activity. RE consists of four key activities which are elicitation, documentation, negotiation/validation, and management. Professional product people provide a discipline to systematically do RE activities with an Agile approach in different iterations. Also, please notice that every piece of documentation needs to have a purpose. If you want to document your requirements, the purpose could be to support legal compliance, preserve valuable information, facilitate communication, or support thought processes.

Check out: Agile Product Management: A Study Guide for PMs

Myth 3: User stories are enough in Agile

Agile product teams, especially the ones which perform within the Scrum framework have a tendency to work with User Stories. Due to the fact that Scrum is a framework, it is neither prescribes nor obliges the team to use a specific technique to describe the user’s needs.

So, the truth is User Stories in many situations are not enough to describe every aspect of user situation, current experience, the ideal future experience, pains, gains, and how to turn these into a good-enough requirements statement.

The Reality: RE in Agile Environment

When product people want to talk about Requirements Engineering in Agile environments, they almost always use “Agile Requirements Engineering”. Actually, this mindset isn’t correct. Requirements Engineering is a completely separate discipline. It has a separate mindset of its own, its principles, and a variety of techniques. So instead of using “Agile Requirements Engineering”, it is better to use “Requirements Engineering at Agile” or what IREB calls, RE@Agile. In an Agile environment, product people should consider the RE, as a continuous process. It does not happen just as a set of upfront activities.

In fact, it’s a combination of upfront activities and continuous activities during iterations. Some examples of upfront RE activities in Agile are defining the product vision, high-level business goals, knowing the stakeholders, and the product scope. In addition, All the RE core activities are going to do by the product people during the iterations. These include Requirements elicitation, documentation, negotiation/validation, and management.

Applying these core activities is mainly a product owner or product manager job. But, the whole Agile team needs to participate in order to have a good-enough and human-centered requirement to develop.

For requirements elicitation in Agile, product people can benefit from a broad range of techniques within their projects. Examples are:

  • Qualitative and quantitative interviews
  • Questionnaires
  • Observation techniques
  • Artifact-based techniques (i.e. reuse, system archeology)
  • Creativity techniques (i.e. Design Thinking, Design Sprint)

These techniques can support the idea of requirements in a User Story or JTBD formats, which is a basis for structured discussion rather than a prescription for implementation.

Before documenting requirements, you have to determine the purpose behind every document. In an Agile world, documentation is considering a crucial activity that fosters communication between the product people and stakeholders. Considering documentation as an evolving continuous activity that creates documents for one of these purposes:

  • Legal purposes
  • preservation purposes
  • Communication purposes
  • Thinking purposes

When you determine the documentation purpose, you can go through techniques and artifacts in RE and Agile to completely create a clear well-written document during iterations.

The major goal for requirements validation and negotiation is to identify conflicts in requirements and also identify missing, ambiguous, and incorrect requirements. Based on Empiricism, Agile values inspection and adaptation. This mindset helps product people to continuously inspecting the validity of the requirement and adapting the product backlog based on new findings. Agile methods strive to validate requirements through early and frequent feedback on valuable product increments which is completely helpful for product people to reduce waste in their Requirements Engineering activities and results.

unknown persons using computer indoors

Unlike traditional requirements management, product people use backlogs to keep only the latest and best version of all requirements that should implement within development iterations. Requirements management activities that have to consider in backlogs are:

  • Requirements Prioritization:

Product people try every possible way to prioritize requirements based on business value. Here, the value is the most important aspect that shapes prioritization. Impact-Effort matrix and MoSCoW are two common techniques for requirements prioritization in Agile.

  • Requirements Estimation:

Agile estimation isn’t a prediction. It is the best guess that developers think the certain product backlog item needs to consider as a DONE item. User Story Points and T-shirt Sizes are two kinds of estimation techniques to use in RE@Agile.

All the mentioned RE core activities including elicitation, documentation, validation/negotiation, and management need to consider in an Agile product management and development environment. It totally depends o product people and the Agile development team to choose the right technique to fulfill these activities based on product scope, context, and also team capabilities.

Source: This article was written based on IREB‘s guidelines for RE@Agile.

About the Author

Aidin Ziapour

Aidin Ziapour is a Chief Innovation Officer and certified Product Management expert. He is an official associate member of the International Requirements Engineering Board. Also, he has experience working with several famous corporations and brands such as the Copenhagen School of Entrepreneurship, Axel Springer & Porsche, Amazing Design People List, and System Group.

Product Podcast

Enjoyed the article? You may like this too: