Is it the product owner's responsibility to provide requirements around data mapping/transformation?
I'm a full stack software engineer. I have worked at many companies ranging from fortune 100 companies to startups and this issue is something i have heard different points of view on. This is the situation.
In a software project where there is a need to ingest data from 1 system, implement some business logic on that data and then output the data to another system so it is consumable by the business.
In the above situation is it the product owner's responsibility to understand what the data is that is being ingested and also provide requirements around how to transform/map that data so that it can be output to a system consumable by the business?
If it is not the product owner's responsibility then how can a developer be expected to accurately give a time estimate when he/she must do the research to understand the data, determine if the mapping is possible and then engage the business to see how the mapping should be done in a way that provides value and then do the work?... Given that this would entail a lot of discovery it seems impossible to give accurate time estimations.
Thanks in advance
There's a lot of grey area, but the direct answer to you question according to the Scrum Guide is no - it is not the Product Owner's responsibility to provide data mappings. https://scrumguides.org/scrum-guide.html#product-owner
So... in your situation, the PO has a backlog item that says something like "As a sales exec, I want to see a graph of sales correlated to X demographics." or something like that. Now, either the teams know how that data works (at least well enough to do a rough estimate and start the work) or they don't. If they don't, you might need other types of backlog items, like spikes. A spike is a means to reduce uncertainty and risk.
Now, could you make a spike for every single user story that comes through? Yes... but... this is a very inefficient way of working. A good scrum master is going to encourage the team to explore what they can do to either simplify their data systems or build knowledge in commonly-tapped areas so that this isn't always happening.