Groom a Ticket to Replace a Store's 12+ Age Rating with a Pending Rating

In a 10-minute exercise, you play a software engineer grooming a ticket together with a product manager. The requirement on the ticket: the PlayStation Store is removing its 12+ age rating and adding a Pending age rating. Lead the grooming session: ask the questions you need answered, divide the work, and finish by giving an ETA. ### Constraints and Clarifications - Ten minutes covers all three parts, so prioritize the questions that change the scope or the estimate. - Only the requirement above was given. The store's architecture, the team's size and any deadline are unknown: ask the PM, or state your assumptions. ### Clarifying Questions - Is the interviewer playing the PM, so that your questions get answers during the exercise? - Does the ETA mean code complete, released behind a feature flag, or available to every user? - Which engineers and teams are available, and does this team own the store's client apps as well as its backend? ### Part 1 — Questions for the PM List the questions you would ask the PM before estimating, and explain why each one matters. ```hint Follow the existing 12+ products Think about every product and every user setting that refers to the 12+ rating today, and what must happen to each of them once that rating no longer exists. ``` ```hint An unknown rating still has to behave List the systems besides the product page that read an age rating, and ask how each should treat a rating that is not known yet. ``` #### What This Part Should Cover - What happens to existing data rated 12+ - The behavior of Pending wherever ratings are used, not only how it is displayed - Which surfaces, clients and regions are in scope - Deadline, rollout and compatibility constraints that shape the plan ### Part 2 — Divide the work Break the ticket into tasks that can be assigned and worked on in parallel, and identify the dependencies between them. ```hint One change blocks everyone Find the single decision every other task depends on, and how the other tracks can start before it ships. ``` #### What This Part Should Cover - A breakdown into backend, client, data and release tasks with owners - The dependencies and the order of work - How tracks run in parallel, and how older clients keep working ### Part 3 — Give an ETA Give the PM an ETA and explain how you arrived at it. ```hint Follow the longest chain Size each task, find the longest chain of dependent tasks, and say which open answers would move the date. ``` #### What This Part Should Cover - An estimate built from the task breakdown, not a guess - A range with the assumptions it depends on - The risks that would move it, and when it will be firmed up ### What a Strong Answer Covers - Drives the conversation within the time box and prioritizes the questions that change scope - Notices the hidden scope: existing 12+ products, age checks and parental controls, older clients, localization and regions - A work breakdown with owners, dependencies and parallel tracks - An ETA given as a range with explicit assumptions, neither a single guess nor a refusal - A collaborative tone with the PM that proposes options instead of only listing problems ### Follow-up Questions - The PM says the change must be live in every region by a fixed date that is earlier than your ETA. What do you cut or phase? - Older client versions cannot be updated quickly and would receive a rating value they do not recognize. How do you keep them working? - A product stays Pending for months. What should the store and parental controls do, and who owns resolving it? - Halfway through the work, you learn that one region must keep the 12+ rating. How does your design absorb that?