Judging Whether a User Story Is Ready for Development: A PM Readiness Checklist

You have written a user story and added it to your team's backlog. How do you decide whether it is ready for the team to start building? Explain the criteria you check and how you confirm that the story meets them. ```hint Ready for the people who build it Picture an engineer and a tester picking this story up tomorrow. What would they need in hand to start it and finish it in one iteration without coming back to you with questions, and what could block them halfway through? ``` ### Clarifying Questions - Does the team work in fixed sprints with a planning meeting, or in a continuous flow such as Kanban, and does it already have a written definition of ready? - Is this a customer-facing feature, a technical or platform story, or a bug fix? The checks differ somewhat between them. - Does the story depend on another team, on design work that is still open, or on an external system? - Does the team estimate its work, for example in story points? ### What a Strong Answer Covers - A concrete readiness checklist: user and value, acceptance criteria, size, dependencies, design and an estimate. - Acceptance criteria that are specific and testable, and how they connect to the team's definition of done. - Readiness confirmed jointly with engineering, design and QA during refinement, not declared by the PM alone. - What to do with a story that fails the check, such as splitting it, running a spike or resolving a dependency first. - Judgment about how much detail is enough, so readiness does not become a bureaucratic gate. ### Follow-up Questions - The team marks stories as ready, but many still spill into the next sprint. What do you investigate? - How would you split a story that is too large for one sprint while keeping each piece valuable to users? - How does a definition of ready differ from a definition of done, and what goes wrong when a team has only one of them?