Product Backlog Refinement
The PO comes with more opportunities for automation. These opportunities need to be reviewed, sized and an effort estimation need to be provided, i.e. a discovery session is needed.
What you're calling a "discovery session" is actually a defined event in Scrum called Product Backlog refinement.
[Refinement] is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Your real issue appears to be that the Scrum Team hasn't allocated sufficient time for this essential activity. This is most likely due to the 100% utilization fallacy and/or process failures during Sprint Planning.
The Scrum Team should be allocating up to 8 hours in a two-week Sprint for Backlog Refinement. This activity should always be factored into the Scrum Team's capacity planning activities, especially during Sprint Planning. In particular, the Development Team should be adjusting its forecasts to ensure sufficient capacity for all framework activities, including refinement. Failure to charge framework overhead to team capacity reduces transparency, and often leaves the team over-committed once the framework's activities are factored into the amount of work a team can complete in a single iteration. Agile frameworks require sufficient slack to remain sustainable!
Accounting for Refinement Explicitly
If the Scrum Team lacks the process maturity to reliably scope Sprint Goals to available Sprint capacity, it may be necessary for the Product Owner to explicitly include refinement activities in the Product Backlog. This will force the Development Team to include those activities in estimates and the Sprint Backlog, and makes refinement a visible deliverable for each Sprint.
Accounting for Refinement (and Other Activities) Implicitly
Alternatively, the Development Team's forecast could be reduced by 10% to implicitly include refinement in its Sprint Planning. For example, if the team has a sustainable average velocity of 25 without accounting for refinement, no more than 22 points should be pulled into the Sprint Backlog each Sprint.
After accounting similarly for other Scrum activities, I'd actually recommend structuring your Sprint Goals around a median of 80% of available team capacity each Sprint to ensure sufficient slack to sustain the pace of development indefinitely.
Other Framework Considerations
There's a lot more to unpack in your question. Many of the underlying issues hinted at in your question are deserving of separate questions, but are too broad to address in depth within a single post. I'll give some of them a quick gloss here.
- Velocity should be used primarily as a capacity planning metric after applying suitable fudge factors. It is not supposed to a measure of productivity or a management target, so don't use it that way.
- Scrum values a sustainable pace of collaborative development over packing each Sprint to the brim. Don't chase utilization metrics!
- Use capacity planning to make each Sprint an efficient time box for achieving clear goals and helping the team work better. Don't use the framework to force people work harder or faster; that never ends well for anyone, including the business and its customers if quality drops as a result of insufficient slack.
- Each Sprint must have a Sprint Goal. Without one, you can't effectively scope work for the Sprint, consistently deliver on Sprint Goals, or routinely achieve the Development Team's forecasts.
- Story spikes are time-boxed, exploratory user stories with results that feed effective estimation of more complex user stories and epics. As a rule of thumb, such stories should be treated as work for a future Sprint, with the results of the spike feeding refinement and planning.
- As a general rule, the output of a story spike is an input to a Sprint Review or Backlog Refinement.
- In most cases, story spikes shouldn't lead to additional work in the current Sprint.
- Follow-on work flowing from a story spike should be placed onto the Product Backlog as future work to be estimated, prioritized, and planned for subsequent iterations.
- Agile release planning is based on a sustainable cadence, and optimizes for predictability and adaptation rather than individual or team utilization metrics.
- Fixed-scope or fixed-effort planning at the project level is not agile, and will generally result in a brittle project plan with poor product quality.
In short, the problems you're facing may not be simply the result of insufficient team capacity for refinement. It's definitely worth spending several Sprint Retrospectives (or even carving some near-term time out of a following Sprint) to inspect-and-adapt the team's processes.
Parting Thoughts
Quoting a slide I wrote for one of my recent coaching engagements, I'll leave you with this thought:
A misapplied Scrum framework is like a chainsaw. It's a lot more efficient at cutting down trees than a butter knife, but it's also much more likely to cause bodily harm when used improperly.
The application of agile principles doesn't require a perfect process on day one, or even day 501 of an 18-month project. The intent is to create time and opportunity for continuous improvements to the product, the process, and the workflow. Start where you are, and then iterate towards a more sustainable process!
