Agile requirements management: the essential core elements for successful IT projects

IT solutions are increasingly being realized according to the lean start-up principle. Starting with the initial development of a product focused on the core functions for market launch ("Minimal Viable Product - MVP"), the product is further developed and optimized after go-live through direct market feedback.

This requires a corresponding rethink, including in requirements management. What are the key core elements that determine the success or failure of a software project in agile requirements management?

A question to which there are probably many different answers. In the following blog post, we want to approach the topic on the three levels of "process", "tooling" and "mindset" and take a practical look at how agile requirements management can be considered in each of these areas. Most of the content comes from the presentation we gave at ModernRE 2019 in Berlin.

The process: From the idea to the specified requirement

In a project, thematic responsibility lies with the specialist department. It therefore regularly creates and updates the vision of the product - the target image. Many ideas are derived from this vision in order to achieve this target image.

The technical responsibility lies with the IT team. The IT team has a slightly different perspective on the product and therefore also different ideas than the specialist department; in the best case scenario, the views of IT and the specialist department complement each other.

Figure: From the idea to the specified requirement

A special feature is that all team members are called upon to enter and detail their ideas in an area set up specifically for this purpose, the so-called idea backlog. Ideas come from individual team members who have identified potential for improvement and optimization, from external studies, in the form of direct feedback from customers or third parties from the market.

At regular intervals, the department reviews all new ideas from the idea backlog. When reviewing the content of the ideas, the already prioritized backlog is considered so that new ideas that are to be pursued further can be prioritized directly. This ensures that the idea with the greatest benefit for third parties and customers or the greatest relevance for the product is always specified in detail next.

In the specification, the topics are specified in detail and in terms of requirements management. Stakeholders, for example, must be identified and introduced to the project in a kick-off meeting. Initial findings and requirements are noted down and prepared graphically in the form of wireframes, mockups or using a suitable type of diagram. A specification template helps to consider recurring questions and issues in a standardized way so that no important aspects are forgotten. Classic approaches also come into play at this point. Requirements must be collected, analyzed, specified and validated.

Each specification phase is followed by a review of the finished specification. For the review, a group of participants consisting of the specialist department and a dedicated IT contact is invited to provide feedback on the specification. In order to check technical risks and feasibility, the IT team should work closely together. In addition, colleagues from IT take a different perspective and, for example, uncover edge cases that have often not yet been considered. At the end of a defined period, it is the author's task to consolidate and view the feedback and incorporate it into the specification.

At the end, a final version of the specification (v1.0) is produced, which is supported by both the business department and the IT team. In terms of the process, the finished technical specification is handed over from the business department to the IT team in the IT definition, the last connections are considered and a uniform understanding is established. User stories for the software development product backlog are then derived, defined, prioritized and detailed from the specification.

Tooling in a collaborative & distributed working environment

A great process alone is not enough! Tools are needed to enable and support this collaborative approach. In most cases, two tools are used in combination, for example JIRA and Confluence from the Atlassian Suite, to map this process.

A Kanban board is created in a ticketing tool (figure: requirements board in the ticketing tool). All process steps are mapped there in order to maintain an overview of all topics in the process. The tickets in the "Ready for Specification" status represent the already prioritized backlog, which is fed from the idea backlog. Ideas that are not relevant to the product are no longer considered here. Topics that are currently being processed - whether in the creation of the specification ("In Specification") or in review ("In Review") - are dragged and dropped into the corresponding status. By linking the ticket to the specification, it is possible to jump from the ticketing tool to the collaboration tool (explanation in the following paragraph) with a single click. This is also possible in the opposite direction. This avoids unnecessary tool and system breaks and makes workflows more efficient. From the specialist department's point of view, a specification is completed after the review has been completed when it is handed over to the IT team ("handover to IT"). In order to ensure complete documentation, it is necessary to add the implemented functional enhancements ("Documentation done"). Only now is the point in time reached at which one can speak of an implemented requirement with a clear conscience.

Figure: Requirements board in the ticketing tool

The documentation of the specification and the review take place in a collaboration tool. It is possible to link the corresponding tickets and specifications between the two tools in order to be able to jump directly from one area to the other. In addition, workshops can also be documented in the collaboration tool and linked directly to the specification as decision logs. Thanks to numerous add-ons, the functional scope of a collaboration tool can be individually adapted to the needs of the project and process. For example, wireframes can be created and edited directly in the collaboration tool itself.

Probably the biggest advantage of using a collaboration tool is when carrying out a specification review. Before the specification was moved to the collaboration tool, the review was carried out using a Word document, whereby one version of the document was stored on the file server for each review participant. The task of the requirements engineer was to consolidate the feedback and incorporate it into the specification. If there were duplicate or even contradictory comments in the different review documents, this led to increased coordination and clarification effort with the relevant review participants. By moving to the collaboration tool, the full range of functions can now be used to support and improve collaboration between the review participants and the requirements engineer. The inline comment function (Figure: Specification and review in the collaboration tool) offers the possibility for each review participant to place a comment by marking a text passage, which is visible to all other review participants. In this way, duplication is avoided and discussions can arise that raise new topics or clarify any queries directly. For the requirements engineer, the consolidation effort of the review feedback is significantly reduced, as all comments can now be found in one document and duplications and contradictions are easier to identify and resolve.

Figure: Specification and review in the collaboration tool

At the end of each review, all participants are asked to confirm that the review has been completed and to indicate whether further coordination with the author of the specification is desired.

Figure: Review log at the end of each specification

Mindset

For a project to be completed successfully, it needs more than functioning processes and modern tools. An important core element is often overlooked: The mindset. The processes and tools will only work together effectively if the people in the project work cooperatively and are focused on the project goal. Nowadays, however, we often come across so-called silos in projects (e.g. in different departments within a company), which can make collaboration difficult. In the worst case, silos pursue their own goals, which at first glance do not always match the goals of the current project.

Georg Jocham, coach for project managers and executives, refers to a study conducted in 2005 in one of his podcasts on the topic of "silos". Here, social psychologist Mark Levin showed the negative influence silo thinking can have on cooperative behavior beyond one's own group. To this end, Manchester United soccer fans were asked questions about their club at the start of the experiment. It can then be observed that the participants' willingness to help other Manchester fans is many times higher than that of fans of a rival club. In the second part of the study, other Manchester United fans are invited. However, with the help of an initial survey, the focus is not placed on the club, but on the entire English league. Interestingly, the willingness to help people who belong to the rival club that was subsequently observed increased massively. It reached almost the same level as cooperation with one's own club colleagues.

The study shows how strikingly cooperation behavior differs: Depending on which group people feel they belong to at the time and whether their counterpart is also part of this group or not. In addition to the dangers that silos can harbor, the study already shows a possible solution to escape the dilemma. People who work together in a project across different departments or companies need a common project identity. This must be established as early as possible in the project, e.g. by communicating the common project goal in the joint kick-off at the beginning of the project.
Once a project identity has been created, it must be ensured that it endures. Within this project team, two fundamental values have emerged that are of great importance for cohesion and functioning cooperation within the group: Appreciation and trust.

Appreciative interaction in the project can be expressed in many different ways. For example, it is appreciative to ask others for their opinion or to thank them for the work they have done. A high level of appreciation in the project can lead to the team showing greater loyalty to the success of the project.
A high level of trust also plays a not insignificant role in whether a team can make optimum use of the jointly established processes and tools. To this end, it must be ensured that everyone involved can rely on the fact that the entire team is focused on the success of the project and that addressing risks, errors and contributing their own opinions is seen as a contribution to this success. In projects where there is a high level of trust, transparency increases and the fear of contact in technical discussions and written exchanges is greatly reduced. It becomes more about the matter at hand. Transparency in particular is an essential prerequisite in agile frameworks such as Scrum.

Illustration: Appreciation and trust in the project

Conclusion

Each of the three topics above would fill more than one lecture. This was also reflected in the agenda for this year's ModernRE 2019. For example, the conference featured separate presentations on the use of individual tools in the requirements process and the interaction of ticketing and collaboration tools. The topic of mindset was also addressed in an exciting presentation entitled "How teams become really strong".
Even if the framework conditions in IT projects are very different, it is still worth taking a close look at your own agile requirements process from time to time and revising it if necessary. This is particularly easy if you work with tools that provide the necessary flexibility.

What all projects certainly benefit from, regardless of the framework conditions, is an appreciative and trusting approach within a common project goal.

Co-author Findan Eisenhut

Further links

10 success factors for requirements management in large-scale agile software projects

Customer satisfaction through fulfillment of requirements - the Kano model