• Product owners often only have about 10% of their time available for the role. 

• A rule of thumb says about 30% is necessary. 

• Developers expecting pre-digested chunks of requirements want 100% and more.

• The agile solution principle is based on Inspect and Adapt

• My favourite approach to solve the problem is for the team to take on the 90% in cross-functional mode

The role of product owner (PO) is difficult to fill in agile teams, because the demands are huge. What can be done if the PO is not up to the role, and a gaping hole opens up in the requirements? For agile teams this isn't really a problem: get rid of dogmas and fill the hole together.

"Who actually writes the user stories? The product owner has to do that, right? But what if they won't or can't do it?" This is one of many questions that eleven practitioners discussed during the Zühlke training course on "Requirements in agile software development".

Naturally, product owner refers to the corresponding role in the scrum, and quite often this role is occupied by players who – despite all the demands from the gurus – can only meet its requirements to a limited extent. After all, product owners also tend to have a day job that can already take up 100% of their time (e.g. as a manager) and a life outside of work, whereas a rule of thumb says that this role should account for about 30% of the product owner’s workload.

The team can get annoyed by this situation and force the product owner to cooperate by acting along the lines of: "The requirements are unclear, so we can't do anything". However, this demand is unrealistic and only fuels the conflict further. Product owners are responsible for requirements engineering (RE). It is not their job to spoon feed the requirements to the team in the form of user stories. This would quickly become a 100% task in its own right.

The system conflict described above can be summarised as follows. Product owners often only have about 10% of their time available for the role. A rule of thumb says about 30% is necessary. Developers expecting pre-digested chunks of requirements want 100% and more.

It is precisely in a situation such as this where we need to be agile! Systemic conflicts of this type are now routine. The agile solution principle is based on Inspect and Adapt. In other words, understand the situation and then do away with methodical dogmas, old hat methods and blaming others, to address the question: how do we arrive at the best possible product?

In this conflict, the analysis reveals a 90% hole in requirements engineering. 

So 90% of the tasks relating to the requirements area are left undone. In particular, the 100% scenario included the following:

1. Create a common vision
2. Get VIPs on board
3. Keep the scope under control (agile slang: backlog management)
4. Optimise benefits and costs (agile slang: conversation, in RE also known as requirements negotiation)
5. Work out a coherent solution in detail (user stories slang: card, conversation, confirmation)

A 10% PO will be kept busy with (1) and (2), with limited time for engaging in discussions under (3). But even a PO who only achieves (1) and (2) is a big win for the team!

Here are a few approaches used by the participants in practice to bridge the missing 90%:
●    Replace the product owner with someone who can contribute 100%.
●    Free up 30% of the product owner’s time from day-to-day work.
●    Use a product owner proxy, who is mainly responsible for tasks (3) and (4).
●    Include specialist representatives in the team, especially for (5).
●    Include business analysts in the team, especially for (3) to (5).
●    Use a different role model.
●    Team takes on the 90% in cross-functional mode.

My personal favourite? The last approach. 

To conclude, one of the participants sums up their findings: 
Requirements engineering is just as essential in an agile environment as in a non-agile one. It merely happens to be performed according to agile principles – controlled, for instance, with user stories. 
This statement is quite suitable as a take-home message from a course on this topic.

Many thanks to the participants for the interesting discussions!