
The requirements management for agile projects forms the basis for the project, as it is for traditional projects. With agile projects and also with Scrum the requirement management differs however in substantial points from that in traditional projects after the waterfall model. In this article, you will learn about the differences and how the requirements are identified and processed until the first product backlog is ready.
The Difference in Requirements Description for Traditional and Agile Projects
In traditional projects, the requirements are identified as completely as possible at the beginning of the project in the definition phase and are described precisely. They are then approved by the customer, project sponsor or a special department. Only then does the implementation of the requirements in the subsequent phases begin. This may be very useful for some types of projects (e.g., if you are building a house or developing an aircraft). In many software projects, the requirements are not yet fully known at the start of the project, they often change, or new ones are added. The traditional project approach according to the waterfall model certainly does not make sense here.
In Scrum, the Product Owner represents the needs of customers, users and other stakeholders. This means that the Product Owner is responsible for the requirements, determines which requirements are implemented and in which order.
Requirements are identified in Scrum during the entire project duration and are repeatedly re-prioritized. In the following figure you can see the difference between agile projects and traditional projects. The big advantage of software is, of course, that nothing physical is produced and, therefore, with changes and new requirements, one is much more flexible here.

Who Delivers the Requirements?
The Product Owner is responsible for the requirements. However, the Product Owner will not be the main source of requirements. As you probably already know, the main source of requirements are the customer and the users. A Product Backlog in which all requirements come from the Product Owner is a bad sign.
It is a good sign when others also make a contribution. Especially when it comes to non-functional requirements, the experience of architects or other specialists, for example, is needed. Perhaps one team member brings experience from a similar project they worked on for another client. This is when the Product Owner is required to bring all this knowledge, experience and customer and user needs together.
The contribution of the Scrum Team in requirements management has the following advantages:
- When the Scrum Team members are actively involved, they feel jointly responsible for the requirements. That’s much better than the attitude: “I only do what I’m told.”
- If more people think about what users want or what the system should do, more creativity will flow into the problem.
- Developers encouraged to contribute ideas to the Product Backlog will necessarily take the time to learn more about the users, goals, competitors and the product. This knowledge will help the developers develop the functionality.
However, in the end, this does not mean that a Product Owner has to react to all the ideas of others. But almost certainly, some of these ideas will be worth following up on.
The Product Owner decides what should be developed, but, as already mentioned above, not all ideas should come from them. If others contribute to the Product Backlog, it is much more likely that the team and the project will be more successful.
In the following sections, you will learn what tools the Product Owner uses to find, analyze and record the requirements.
Identifying the Requirements
As you have already read in the previous section, the requirements can be identified and analyzed by the stakeholders using various methods. At the beginning of the project, for example, you will use the following methods:
- Interviews
- Observing users at work
- Workshops
In the further course of the project, new requirements are constantly being identified, existing ones adjusted or rejected. For this purpose, the Estimation Meeting (Backlog Refinement Meeting) is usually used.
The Requirements Workshop
One of the most efficient ways to identify requirements is a 1 to 2-day requirements workshop with customers, users and other stakeholders. It is important that developers also participate, because they will implement the requirements later.
The advantage here is, that the developers hear the requirements directly without “transmitters”, which avoids communication errors and thus misunderstandings and gives them a better understanding of customer needs. They can also ask for clarification immediately.
First, the Product Owner introduces the product version to the participants and then a brainstorming session takes place to identify the requirements. Workshop participants are more active when they write the requirements on pinboard cards. Then you can group the same or similar requirements on a wall so that they can be discussed in detail.
It is ideal if the participants define the requirements as user stories that have a business reason and value and contain acceptance criteria that will define when the requirement is implemented (Done). User Stories will be new for some participants. Therefore, you should make a short introduction to this kind of requirement description at the beginning of the workshop.
Understanding Customer Requirements
Understanding the customer’s requirements is not always easy, because the customer often talks in terms of solutions instead of requirements.
Here is a simple example: “The application must have a login screen”. This is not a requirement. A requirement should be solution-neutral and should read: “Ensure that only authorized people can execute application X”. This requirement can be solved in various ways (e.g., with a login screen, single sign-on, fingerprint scanner).
Another important point is to understand WHY the customer has this requirement. This to ensure that we do not talk about solutions and to understand the business benefits behind them. Here are two thing you can say to the customer: “Help me understand why this is important to you” and “What business benefit do you expect from it?”
Ordering the Requirements to the First Product Backlog
Finally, you can hang up the cards in the form of a Product Backlog ranked by business value. Here, the Minimum Marketable Feature Set (MMF) can also be considered, which represents a minimum saleable delivery .
This is your first rough view of the Product Backlog with a ranking, but without subdivision into Sprints and releases. You will do this task later with the Developers.
The requirements workshop provides all participants with a common understanding of the initial situation and the requirements for the product. This also ensures that these are correctly described. The customer or the responsible departments can then accept these requirements directly at the workshop, eliminating the need for subsequent reviews. The result of the meeting is the initial, approved Product Backlog.
The Product Owner will conduct the first requirements workshop before the first Sprint if possible, so that an initial, roughly-ranked Product Backlog is available for the first Sprint planning. Then, the Product Owner will conduct further workshops as required to continuously capture new requirements and further detail existing ones.
By When Are the Requirements Implemented?
The customer will certainly ask you when they receive each requirement and what the approximate costs will be. You have to put them off until another workshop/meeting, when you can present them this information in detail. You must first perform the following activities with the Developers:
- Clarify and detail the results of the workshop
- Estimate the effort needed for the highly prioritized requirements
- Splitting the first Product Backlog into releases and Sprints
Here is Even More Knowledge
Would you like to learn more about how Scrum can make your agile projects even more successful? My book “Scrum – How to Successfully Apply Agile Project Management and Scrum” takes you an important step further!
Do you know anyone who might be interested in this article? Then simply forward it or share it in your network. Thank you very much!