Requirements engineering is an essential part of developing every software product, no matter how you approach product management and development. The quality of your requirements engineering work and its outcomes directly affect the failure or success of your approach to product management on a project.
The question here is how you can apply new thinking, principles, methods in an Agile product management environment. Well, the surest and most appropriate answer to this question is the bridge between Requirements Engineering and Agile. In this article, you will learn about the myths and realities surrounding requirements engineering in an Agile environment and how to capitalize on it by creating a bridge between the two.
There are many myths and misconceptions associated with Requirements Engineering and Agile. In this section, we’ll talk about common myths that you might hear in your teams and companies on a daily basis. Let’s take a look at them.
Myth 1: There can be no advances in an Agile environment.
Often, even in mature product teams, there is a myth that if you want to follow Agile, you should forget about any prior activities. For the real world, Agile is a misjudgment. You need to go through several preparatory steps (for example, developing a product concept) to create a compass that will guide your development. In addition to coding and testing, you can shape and use requirements engineering in Agile iterations.
Myth 2: Requirements Engineering is Paperwork
Many people working on a product still think of requirements engineering as something like documentation. Requirements engineering consists of four key activities: identification, documentation, reconciliation / verification, and management. Professionals provide the discipline to systematically perform repetitive Agile activities in different iterations. In addition, please note that each piece of documentation should have a specific purpose. If you want to document their requirements, the goal may be to ensure compliance with the law, preserve valuable information, facilitate communication or support thought processes.
Myth 3: There are enough user stories
Agile product teams, especially Scrum teams, are used to working with user stories. Due to the fact that Scrum is a framework, it does not prescribe or oblige the team to use a specific technique to describe the user’s needs.
So the truth is that user stories in many cases it is not enough to describe every aspect of the user journey, current experience, ideal future experience, problems, benefits, and how to turn them into a reasonably good requirement statement.
Reality: Requirements Engineering in an Agile Environment
When product engineers talk about requirements engineering in Agile environments, they almost always use the term Agile Requirements Engineering. In fact, this thinking is wrong. Requirements engineering is a completely separate discipline. It has its own philosophy, principles and many methodologies. Therefore, instead of “Agile Requirements Engineering”, it is better to use “Requirements Engineering in Agile” or what IREB called RE @ Agile. In an Agile environment, product engineers must view requirements engineering as an ongoing process. That is, it is not just a set of preliminary preparatory actions.
In fact, it is a combination of upfront and continuous actions during an iteration. Some examples of preliminary activities in requirements engineering in Agile include defining a product vision, high-level business goals, identifying stakeholders, and identifying a product’s scope. In addition, during the iteration, all requirements engineering work will be performed by product engineers. These will include requirements elicitation, documentation, reconciliation / verification and management.
The application of these core activities is primarily the job of the product owner or product manager. But the team must be involved in order to have good and human-centered development requirements.
Product engineers use a wide variety of techniques to identify requirements in Agile. For example:
Qualitative and quantitative interviews;
Artifact-based methods (i.e. reuse, systems archeology);
Creative techniques (e.g. Design Thinking, Design Sprint).
These methods meet the idea of requirements in the format of user stories, or Jobs-to-be-done, which is the basis for a structured discussion, not a prescription for implementation.
Before documenting the requirements, you must define the purpose of each document. In the Agile world, documentation is seen as an essential activity for facilitating interaction between developers and stakeholders. Think of documentation as an ongoing activity where documents are created for one of the following purposes:
As you define the purpose of the documentation, you can explore the requirements engineering and Agile techniques and artifacts to create a clear, comprehensible document per iteration.
The main purpose of reviewing and agreeing requirements is to identify conflicts in requirements and to identify missing, ambiguous, and incorrect requirements. Agile is based on empiricism and research and adaptation are essential. This mindset allows product creators to continually validate requirements and adapt the backlog based on new findings. Agile practices strive to validate requirements with early and frequent feedback on valuable product increments, which helps developers save time and resources while developing requirements and delivering results.
Unlike traditional requirements management, product engineers use backlogs to store only the latest and greatest version of all requirements that need to be implemented within an iteration. Requirements management activities to consider in the backlog include:
Product specialists try to prioritize in any way based on business value. Here, value is the most important aspect that determines the prioritization. Impact-Effort Matrix and MoSCoW are two common methods for prioritizing requirements in Agile.
Assessment of requirements:
Agile valuation is not a forecast. Rather, the best guess the developers have for any item of backlog that should be considered complete. User Story points and the T-shirt system are two types of assessment methods that can be used in RE @ Agile.
All of the activities mentioned, including identifying, documenting, reviewing / reconciling and managing, need to be considered in an Agile product and development management environment. Choosing the right technique for performing these actions is entirely up to the product managers and the Agile development team, and it needs to be based on the scope of the product, the context, and the capabilities of the team.
Translation prepared as part of the start of recruitment for the course “Agile Project Manager”…
We invite everyone to an open lesson “How to Make Agile Retrospective Useful”… In this webinar, we will sort out popular misconceptions about retrospectives and talk about a set of useful practices so that the team can happily wait for the new retro. Let’s do a very illustrative exercise to deepen understanding. As a bonus, let’s talk about more old-school project management practices that can help manage expectations.