... you are organizing the work of the enterprise, and the Product Owner is looking for ways to get help from the team to prepare requirements and the Product Backlog.
✥ ✥ ✥
All work needs to be accounted for if the Product Owner is to use team velocity for release planning, yet not all development work can be time-boxed.
The Product Backlog is the primary tool for budgeting the work on a project. Its Product Backlog Items (PBIs) are ordered by the Product Owner who takes development estimates into consideration when planning deliveries. Teams are expected to eventually commit to the Sprint Goal and to be confident about their estimates.
However, there is some work which is difficult, or impossible, to estimate. Some analysis tasks require open-ended research to evaluate development feasibility, cost, and tradeoffs. While analysis is usually the Product Owner's job, such analysis often requires input from or work by the Development Team. You can time-box such research, but that usually leads to repeated extensions of the research time box. And while research activities produce insights, they rarely produce the kind of potentially shippable increment expected rom work done in the development part of a Sprint. This raises doubts about doing such work within the Sprint, and about budgeting it on the Product Backlog.
This wouldn't be a problem if the Product Owner Team alone could do the research, because the Product Owners can manage their own time. However, it is often the case that Product Owners have a strong business skill set but a weaker skill set to actually build the artifacts to be evaluated. Yet issues of technology and production often arise as key elements of business risk and, as such, fall within the Product Owner's purview.
Scrum tradition comprises other activities whose work is not tracked on the Product Backlog. Examples include Sprint Planning, drag, Sprint Review, and meetings to create a Refined Backlog.
Compartmentalize the planning work for long-running high-risk business items into periodic meetings that are outside the Sprint budget.
✥ ✥ ✥
Move this work into fora such as the Sprint Planning Meeting, the Sprint Review, and Product Backlog Refinement Meeting. Additionally, the Product Owner may still fund the team to work on well-contained PBIs within the Sprint.
If the Product Owner Team doesn't have the expertise necessary to do analysis that requires expertise in the product technology (e.g., product performance analysis, prototype construction) then the Product Owner can fund the Development Team to do such analysis work in a Spike during the Sprint. Such work is limited to activities that can be estimated with low variance by the Development Team or which the Product Owner and Development Team agree should be confined to a fixed, pre-determined time box. For example, if the Product Owner needs a prototyping tool and can deliver an Enabling Specification that describes what is needed, it is fine to use a PBI to direct the team to do this work. Such a tool feeds the value stream and has demonstrable return-on-investment.