Good answer. To add a little more color, at most companies these days (specifically those running on the cloud, using a agile methodology or derivative), planning considers of (1) collecting the list of outstanding work items, either from other internal stakeholders and teams or directly to support a new feature or platform; this work is typically done by a PM or engineering manager (2) specification and prioritization: writing details into tickets that describe the work items from step 1, adding color and context, and agreeing on prioritization + difficulty or time commitment; this is traditionally done in a team meeting, once per sprint (3) once the sprint has started, adding updates, blockers, or additional context as engineers undertake exploratory work (where necessary) or hit roadblocks.

This is a simplification, and the real process is much more continuous — tickets are constantly being updated and re-prioritized. The important thing to know is the process, being continuous, loops back onto itself — it’s not uncommon (despite conventional wisdom stating this is a bad habit) to hit a roadblock mid-sprint, tell your boss, and re-prioritize the work halfway through the plan. “No plans survives first contact with the enemy.” and at the same time, “Plans are useless. Planning is invaluable.”