CRM development by multiple teams

Question

In a large organization, they recently shaped 4 end to end scrum teams, meaning they can take a user story, and deliver front end, back end, test it and push the code to the main line.

However it has been said that a special team is needed to liaise with the business and stakeholders, in order to do a first pass of the requirements for the system to be built. Therefore, 2 people formed a mini team, one being a tech specialist and the other a business person (ex-PO), in order to do this first pass and agree on requirements. Thereafter, the information, or "big" user stories will be fed down to the other POs via one or more meetings, and each team will decide what they'll do and what not.

Furthermore, it is said that it would be inefficient for all PO to do the job that this initial mini team does, because they will most likely step on each other toes.

I don't know whether this is sustainable in the long term. Most likely it will highlight a bottleneck in the whole approach, however people support that this is the best solution in the short term. Ultimately, we want the POs to be responsible to deliver one piece of functionality of the CRM.

How do you achieve this from the current situation, if at all?

Answer 1

One of the big differences between Scrum and traditional development is the Product Owner role.

The Product Owner becomes the single source of truth for the team in all matters relating to requirements. They distil the stakeholders ideas down to a coherent backlog of requirements and work closely with the development team to ensure their understanding.

However it has been said that a special team is needed to liaise with the business and stakeholders, in order to do a first pass of the requirements for the system to be built

This is a traditional development approach. Creating a 'special team' between the business and the development teams has a number of disadvantages:

• It creates ambiguity around requirements decisions. Who has the final say, the special team or the Product Owner?
• It undermines the Product Owner role such that they no longer own the product.
• It is easy for misunderstanding to arise as information is passed through intermediary teams.
• The key aspect of continuous feedback from the stakeholders is undermined.

it is said that it would be inefficient for all PO to do the job that this initial mini team does, because they will most likely step on each other toes.

This is a peculiar statement. Are the Product Owners incapable of talking to each other?

Answer 2

Do the four Scrum Teams "take" from the same 'backlog'? Does the "main line" describe a single Product?

If you answered 'yes' then I'd be wondering, who is the 'real' PO for this product?

The default position should be one PO per Product Backlog. Often this results in too much work for one person, so consider the Product Owner team pattern i.e. one PO her helpers.

Another suggestion I have is to take a look at scrum.org's Nexus, with a view to it structure rather than suggesting you install it 'as is'. Of course, a scaling framework should only be considered when the costs of handling multiple Scrum Teams exceeds the inherent costs of the scaling framework. I would recommend trying the the Product Owner team pattern first.