name: sprint-planning
description: Use this skill for Agile and Scrum workflows — writing user stories, defining acceptance criteria, estimating story points, generating sprint goals, running retrospectives, backlog grooming, standup updates, or onboarding documentation. Trigger on keywords: user story, sprint, backlog, story points, acceptance criteria, retrospective, standup, DSU, scrum, agile, estimation, epic, ticket.
Sprint Planning
User Story Writing
Format
As a [type of user],
I want [goal or action],
So that [benefit or value].
Acceptance Criteria Format (Gherkin)
Given [initial context or precondition],
When [action or event occurs],
Then [expected outcome].
User Story Example
I want to reset my password via email,
So that I can regain access to my account if I forget my credentials.
Acceptance Criteria:
Given I am on the login page,
When I click "Forgot Password" and enter my email,
Then I should receive a password reset email within 2 minutes.
Given I click the reset link in the email,
When I enter a new valid password,
Then my password should be updated and I should be logged in.
### Story Quality Checklist (INVEST)
- **I**ndependent — can be developed without depending on other stories
- **N**egotiable — details can be discussed
- **V**aluable — delivers value to a user or stakeholder
- **E**stimable — team can estimate it
- **S**mall — completable in one sprint
- **T**estable — acceptance criteria are verifiable
---
## Story Point Estimation
### Scale Reference
| Points | Size | Description |
|---|---|---|
| 1 | XS | Trivial change, well-understood, < 2 hours |
| 3 | S | Small, clear scope, half a day |
| 5 | M | Medium complexity, 1–2 days |
| 8 | L | Complex, cross-cutting, 3–4 days |
| 13 | XL | Very complex or uncertain, needs breakdown |
### Estimation Rules
- If a story is 13 points, break it down into smaller stories
- Points represent **complexity + uncertainty**, not just time
- Estimate as a team — avoid anchoring bias (don't share estimates until everyone reveals simultaneously)
- Use historical velocity to validate sprint capacity
---
## Sprint Goal Formula (FOCUS Model)
A good sprint goal is:
- **F**un — memorable and motivating title
- **O**utcome-oriented — what value is delivered, not what tasks are done
- **C**ollaborative — agreed upon by the whole team
- **U**ltimate — answers "why are we doing this sprint?"
- **S**ingular — one clear goal, not a list
### Sprint Goal Example
By end of sprint, users can sign up, log in, and access their dashboard —
giving us a working auth system to build all future features on.
Standup / DSU Format
Structure
Yesterday: [What I completed]
Today: [What I'm working on]
Blockers: [Anything blocking me — or "none"]
Example (Taglish style for Filipino dev teams)
Good afternoon.
Yesterday, na-finish ko yung unit tests para sa [feature].
Today, mag-a-address ako ng review comments sa [PR] tapos mag-s-start ng [next task].
Wala naman blocker at the moment.
That's all from me, [name].
Backlog Grooming
Grooming Checklist (per story)
Prioritization Framework (MoSCoW)
| Priority | Meaning |
|---|
| Must Have | Critical for this sprint/release |
| Should Have | Important but not critical |
| Could Have | Nice to have if time permits |
| Won't Have | Out of scope for now |
Sprint Retrospective
Format (Start / Stop / Continue)
START: Things we should start doing
STOP: Things we should stop doing
CONTINUE: Things that are working well
AI-Assisted Retrospective Prompt
Given these sprint outcomes: [outcomes]
And these blockers encountered: [blockers]
Generate a Start/Stop/Continue retrospective with:
- 2-3 items per category
- Actionable items, not vague complaints
- One owner assigned per action item
Onboarding Documentation
New Developer Onboarding Checklist
## Day 1
- [ ] Dev environment setup (see README)
- [ ] Access to all required systems (GitHub, Jira, Slack, cloud console)
- [ ] First PR — fix a small bug or add a test
## Week 1
- [ ] Understand the domain and architecture (see ARCHITECTURE.md)
- [ ] Shadow a code review
- [ ] Complete first solo story (1–3 points)
## Month 1
- [ ] Own a feature end-to-end
- [ ] Contribute to architecture discussion
- [ ] Give feedback in retrospective
Repository Intelligence File (CLAUDE.md / copilot-instructions.md)
Every repo should have an onboarding file that answers:
- What does this project do?
- How do I set it up locally?
- What are the coding conventions?
- How do I run tests?
- How do I deploy?
- Who do I ask for help?
