It is clear and undisputed that requirements are still needed even in agile projects. But is the distribution of business analysis and requirements engineering to the other roles effective? Or are dedicated roles the better alternative? Is the elicitation, specification, validation and management of requirements more of a skill set or a discipline?
In many IT projects, whether using classical or agile methods, last year the expectations were only fulfilled in every third project. Only a tenth of the total effort is dedicated to the requirements, although their importance is undisputed.
According to a market survey in spring 2018 with more than 400 participants, 2 out of 3 IT initiatives were implemented according to agile methodologies. The vast majority of them used the Scrum framework as a basis. The remaining projects were implemented in the classic style. Accordingly, the requirements are less and less being collected in dedicated project phases according to “old school”, but rather iteratively and continuously. Nevertheless, it is frightening to note that overall, only every third project met the requirements satisfying.
The new «Trends & Benchmark Study 2019» shows that about 12% of the total project costs and about 16% in relation to the development, are spent on the identification and specification of needs and problems. This is far too little considering that requirements are central artifacts that represent the problems and needs of end users especially with regard to «Customer Centric Design» or «Design Thinking».
Even if the half-life period of requirements is shorter in agile frameworks, it is not profitable to save money here.
- It should be understood and accepted that today’s requirements are changing artifacts and can never be considered finished or final.
- Poor requirements must be actively addressed and clarified through regular refinement sessions. The necessary time must be explicitly requested in order to provide the users of the product with what they really want.
- Missing requirements need to be addressed proactively. This requires appropriate stakeholder involvement and accountability. It helps if you ask yourself the question:
«What value does the product have for the user IF this feature/requirement is missing or omitted?»
- An efficient and effective tool is to visualize the requirements by means of a simple prototype. In this way, the requirements can be validated, adapted and a common understanding can be established.
Although requirements are central artifacts, agile frameworks such as “Scrum”, “Kanban” or “SAFe” neglect the Requirements Engineering. Good requirements themselves do not provide any added value for the user but are the central foundation for the implementation and realization of the desired added value.
Agile paradigms have their origin in software development. The identified user or customer needs (requirements) are considered as given input. If this input is inaccurate, the plan is doomed to fail right from the start. In the increasingly complex world of systems and interacting components (IoT), it is therefore not surprising that, according to the «Trends & Benchmark Study 2019», more than 60% are not satisfied with requirements management.
One problem is that there is neither a BA/RE role in the agile frameworks, nor is it sufficient to deal with how and which «items» get into the «backlog». It is assumed that the solution-neutral formulation of prob-lems is simple, fast and minor. In this respect, most agile frameworks are too narrowly defined and do not sufficiently respect today’s complexity.
Another problem is that the «Product Owner» often has to manage requirements engineering on the side. However, the product owner rarely has the necessary time to deal sufficiently with the needs of the users and to convert them into workable requirements. In addition, they often come from project management and therefore do not have the necessary set of skills to comprehensively fulfill the role of the PO.
As a logical consequence, besides time, skills and experience for requirements engineering are lacking, which in turn leads to bad requirements and dissatisfied end users.
- The discipline «Requirements Engineering» should be given at least the same priority as the de-velopment itself (resources and time).
- Problems or needs have to be formulated at the business level and have to point out the goals and the intended added value.
- Requirements must be formulated in a simple and understandable way. Implicit knowledge must be explicitly formulated in order to validate made assumptions.
- No matter how simple or clear the requirements seem to be, it is imperative to discuss and re-view requirements at an early stage. Users, sponsors, analysts, developers and testers have en-riching perspectives worth considering.
- «Definition of Ready» (DoR) is a very effective and efficient quality gate for the specification of requirements and must therefore be defined and continuously followed.
A dedicated role is not required for good and continuous specification and management of requirements. However, it requires well and specifically trained employees. They are critical to success and should be highly professionalized. The skillset of the employees is crucial for success.
For the elicitation and appropriate specification of requirements, individuals with both business and meth-odological skills are employed. At the same time, the needed social and communication skills increase due to the stronger and continuous involvement of stakeholders. It is therefore a very versatile and broad job profile that can only be fulfilled by a single person in the sense of a role with difficulties and at high costs.
From an entrepreneurial point of view, it is therefore obvious that the tasks of business analysis and re-quirements engineering should be distributed among several people instead of concentrated in one role – a change from «roles» to «disciplines». This requires, however, that the appointed employees have the nec-essary skills to perform the tasks assigned to them with sufficient quality. If these are missing, the result is often a high degree of dissatisfaction with the requirements and the product itself.
- A useful tool is the creation of a skill matrix of the team, which takes the skills and specific strengths of the people into account when assigning tasks.
- If specific know-how is not available, specific education and training of employees is an invest-ment that always pays off – saving money here is short-sighted. There is a large number of prac-tice-oriented courses with experienced technical and methodical experts.
- Identifying and collecting needs and problems is crucial, but not trivial. The social and commu-nication skills («soft skills») of the employees involved should be explicitly and comprehensively trained.
- There are countless survey techniques for requirements. These should not only be chosen based on the availability of the stakeholders or the time required, but also on the skills and experi-ence of the employees.
To summarize, it can be said that the roles of Requirements Engineer and Business Analyst are not dead, even in an agile context. It is neither right nor wrong to use a dedicated role for the elicitation and specification of requirements or to organize it in disciplines (task-based) – rather it has to be adapted to the situational circumstances. Whichever option you choose, in the end it is the skillset of the employees involved that is critical. In an agile context, the Product Owner does not replace the Business Analyst and the Requirements Engineer. Most projects and products are too large and complex for this. It is therefore important that business analysis and requirements engineering are DONE by employees who have the right set of skills. In agile projects it makes more sense to organize the tasks in a goal-oriented way – according to the motto: “Follow the goal rather than the role”.