Plan a sprint from the backlog and the team's capacity

Draft a sprint plan from the backlog below, for {{team}} to discuss and commit to in sprint planning, so that the team starts the sprint with one clear goal, a set of stories that fits the time it really has, and the risks out in the open.

Sprint dates and length: {{sprint_dates}}
Product owner's priorities or proposed sprint goal: {{goal_input}}
Team availability (people, days off, meetings, support or on-call duty): {{availability}}
Recent velocity or throughput, and how we estimate: {{velocity}}
Margin we keep for unplanned work: {{margin}}

The backlog, in the product owner's order, with estimates, acceptance criteria and dependencies where we have them:
"""
{{backlog}}
"""

Our definitions of ready and done, if written: {{definitions}}

Produce:
1. Sprint goal: one sentence describing an outcome, not a list of tickets, for example "Customers can reset their own password from the app". That example shows the form only.
2. Capacity: available person-days after time off and other duties, and the planned load in points or stories, worked from recent velocity adjusted for availability, less the margin. Show the arithmetic.
3. Committed stories: a table with the columns Story, Estimate, How it serves the goal, Dependencies, Ready?. Keep the product owner's order unless a dependency forces a change, and say where it does.
4. Stretch items: up to three, taken only if the committed work finishes early.
5. Not taken: stories near the top of the backlog that were left out, and why (too big, not ready, blocked).
6. Risks, and questions to settle in the planning meeting.

Mark a story "Not ready" if it has no acceptance criteria, depends on something not yet delivered, or is bigger than the team usually finishes in one sprint, and suggest how it could be split.

A good plan is one the team could explain to a stakeholder in a sentence and still believe in halfway through the sprint. This is a draft for the team: the team, not the plan, makes the commitment. Do not change estimates, reorder the product owner's priorities for any reason other than dependencies, or invent acceptance criteria. Keep it under 500 words, not counting the tables.

If velocity is not given, plan from available person-days and say the load is a first guess for the team to check. If no margin is given, leave some, state how much and why. If the goal input and the top of the backlog point in different directions, raise it as the first question instead of choosing between them.