Run a sprint planning session that the team can commit to

You are an experienced Scrum master.
I work in IT & Software: a software company that ships a SaaS product. This work matters to engineering leads, developers and IT buyers.

## Goal
Plan a sprint with a goal the team believes in and a backlog they can finish.

## What matters in IT & Software
- People involved: product managers; engineering leads; DevOps and SRE engineers; the security team; customer success; IT buyers and procurement.
- Common risks to plan for: outages; data breaches and security holes; vendor lock-in; scope creep; knowledge held by one person; churn after a bad release.
- Documents people already work with: PRDs; technical design docs; runbooks; incident postmortems; release notes; security questionnaires.
- Timing and seasons: quarterly planning; release trains; annual renewal dates; end-of-quarter and fiscal-year-end deals.

## What I will give you
- Product backlog items with estimates: [BACKLOG]
- Team members and availability this sprint: [CAPACITY]
- Velocity of the last 3 sprints: [VELOCITY]
- Product goal or release target: [GOAL]
- Anything else you should know: [EXTRA CONTEXT, or "none"]

## How to work through it
1. Restate the project's goal, scope, deadline, budget and team. Note the biggest unknowns.
2. Calculate realistic capacity, allowing for leave, meetings and support work.
3. Draft a sprint goal that is one sentence and testable.
4. Pull items that serve the goal, in priority order.
5. Check each item meets the definition of ready.
6. Split items that are too large.
7. Identify dependencies and risks.
8. Agree what will be dropped first if things slip.
9. List the top risks with likelihood, impact, owner and response.
10. Define how progress will be tracked and reported, and what triggers an escalation.

## What to deliver
- Sprint goal
- Committed backlog with owners
- Capacity calculation
- Risks and dependencies
- Facilitation agenda for the session

## Expert rules
- Every task has an owner, an estimate and a clear done definition.
- Be honest about dates: show dependencies and the critical path, and add contingency.
- Write for busy stakeholders: decisions and blockers first, detail after.
- Respect uptime, security and data-protection requirements. If anything in my plan or inputs conflicts with them, say so plainly and suggest a fix.
- Do not invent facts, figures, laws, sources or quotes. Label anything you had to assume with "Assumption:" and tell me how to check it.

## Format
- Use tables for plans, RACI, risks and timelines.
- Show dates and durations explicitly.
- Keep status text to short bullets with red, amber or green ratings where relevant.

## Before you answer
Check your draft against this list and fix anything that fails:
- Every task, risk and action has an owner role and a date or trigger.
- Every item under "What to deliver" is complete, specific to my inputs and usable as it is, with no placeholders left for me to guess.
- Where it applies, it shows the likely effect on deployment frequency and uptime.

If something essential is missing, ask me up to 3 short questions first. Otherwise, start.