# Sprint Planning > **Sprint & Release Planning**: Helps with sprint planning, backlog grooming, story estimation, release planning, and roadmap creation. Use this skill whenever the user wants to plan a sprint, groom the backlog, write user stories, estimate tasks, plan a release, create a roadmap, prioritize features, or structure a planning meeting. Trigger when the user mentions 'sprint', 'backlog', 'story point… - **Type:** Skill - **Install:** `agentstack add skill-camilooscargbaptista-cto-toolkit-sprint-planning` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [camilooscargbaptista](https://agentstack.voostack.com/s/camilooscargbaptista) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [camilooscargbaptista](https://github.com/camilooscargbaptista) - **Source:** https://github.com/camilooscargbaptista/cto-toolkit/tree/main/sprint-planning ## Install ```sh agentstack add skill-camilooscargbaptista-cto-toolkit-sprint-planning ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Sprint & Release Planning This skill helps you run effective planning processes — from writing good user stories to building quarterly roadmaps. Adapt the level of formality to your team's size and culture. **Before producing any planning output, read `../quality-standard/SKILL.md` and apply its self-verification protocol, decomposition rules, and edge case prompting.** ## User Story Writing A well-written story communicates intent without over-prescribing implementation. Every story MUST be production-ready with no ambiguity or missing acceptance criteria. ### Format ``` As a [type of user], I want to [action/capability], so that [benefit/value]. ``` ### Mandatory Story Requirements Every story MUST include ALL of the following before it enters a sprint: 1. **Acceptance Criteria (minimum 3 scenarios)** in Given-When-Then format - Happy path scenario (the normal case) - At least one error/failure scenario - At least one edge case or boundary scenario 2. **Definition of Done checklist** (concrete, testable items) - Code reviewed - Tests written and passing - Acceptance criteria verified - Documentation updated - No console errors/warnings - (Add team-specific items) 3. **Dependencies** (explicit list) - Other stories that must complete first - External APIs or services required - Data or configuration changes needed - Third-party integrations 4. **Estimated Complexity** (S/M/L or story points) - Use Fibonacci: 1, 2, 3, 5, 8, 13 - If >8, story is too large — split it 5. **Story Quality Checklist (INVEST)** - **I**ndependent — Minimal coupling to other stories - **N**egotiable — Implementation approach is flexible - **V**aluable — Delivers measurable user or business value - **E**stimable — Team can estimate within a confidence range - **S**mall — Completable in ≤1 sprint - **T**estable — Acceptance criteria are verifiable ### Complete Example: Add PIX Payment Method ``` Title: Add PIX payment method to checkout flow As a Brazilian customer, I want to pay with PIX at checkout, so that I can use my preferred, instant payment method without credit card fees. ## Acceptance Criteria ### Happy Path Given a customer with a valid PIX key in their payment methods, When they select PIX at checkout and complete the payment flow, Then the payment processes instantly, they receive an order confirmation email within 2 minutes, and the order status shows "Paid" in their account. ### Error Case: Invalid PIX Key Given a customer enters an invalid PIX key during payment, When they submit the payment form, Then the system displays "Invalid PIX key format" error message, highlights the input field in red, and suggests the correct format (email, phone, CPF, or random key). ### Edge Case: Duplicate Payment Attempt (Race Condition) Given a customer has submitted a PIX payment but clicks "Submit" again immediately, When the system processes both requests concurrently, Then only one charge is applied, a duplicate prevention lock is acquired, and the customer is informed "Payment already processing—do not refresh." ### Boundary Case: Large Transaction Amount Given a customer attempts to pay R$50,000 via PIX, When the transaction exceeds the PIX single-transfer limit (R$4,992), Then the system displays "Amount exceeds PIX limit" and offers to split into multiple transfers or suggests alternative payment methods. ### Boundary Case: Very Quick Payment Given a customer completes PIX payment verification in 5 seconds (investigate processor slowness) - Alert if duplicate webhook rate > 5% (potential retry storm) 4. Verify metrics appear in monitoring dashboard Acceptance: - Metrics queryable in monitoring system - No sensitive data in logs - Alerts configured and tested with mock scenarios - Dashboard shows PIX transaction success rate Depends on: T2, T3, T5 ## Task T7: Document PIX Payment Flow and Integration Task: Write documentation for PIX integration File(s): - docs/payment-methods/pix.md - docs/api/webhooks.md (update) - README.md (update payment methods section) Details: 1. Write high-level architecture diagram (user → checkout → processor → webhook → order) 2. Document API endpoint: POST /checkout with pix payload example 3. Document webhook schema: what fields are sent, how to verify signature 4. Add troubleshooting section: common errors and solutions 5. Add rate limits and retry strategy 6. Add security considerations (no storing full PIX keys, idempotency strategy) 7. Update README to list PIX as supported payment method Acceptance: - Documentation is complete and accurate - Code examples run without errors - Links to related sections verified Depends on: T1-T6 (documentation only, can start earlier) ``` This task breakdown ensures: - No task takes >4 hours - Each task is testable in isolation - Dependencies are explicit and ordered - Implementation is unambiguous - Junior developers can execute without asking clarifying questions ## Sprint Planning Meeting ### Prep (before the meeting) 1. Product owner has a prioritized backlog with refined stories 2. Top stories have acceptance criteria and basic technical context 3. Team's velocity from last 3 sprints is known 4. Carry-over items from last sprint are identified ### Meeting Structure (2 hours max for a 2-week sprint) **Part 1: What (30 min)** - Product owner presents sprint goal and top-priority stories - Team asks clarifying questions - Align on what "done" means for each story **Part 2: How (60 min)** - Team breaks stories into tasks - Estimation (story points or t-shirt sizes) - Identify dependencies and risks - Team commits to a realistic sprint backlog **Part 3: Commitment (15 min)** - Review the sprint goal - Confirm total points are within velocity range - Flag any concerns or blockers - Everyone agrees they can commit ### Estimation Guide Use Fibonacci (1, 2, 3, 5, 8, 13) or T-shirt sizes (XS, S, M, L, XL). | Points | Meaning | Example | |--------|---------|---------| | 1 | Trivial, well-understood | Fix a typo, update a config | | 2 | Small, straightforward | Add a field to an existing form | | 3 | Medium, some complexity | New API endpoint with validation | | 5 | Significant, multiple components | Feature with frontend + backend + tests | | 8 | Large, uncertainty involved | New integration with external service | | 13 | Very large — consider splitting | Full authentication flow from scratch | If a story is >8 points, push to break it down. Stories that are too large hide complexity and create surprises mid-sprint. ## Release Planning ### Release Checklist ```markdown # Release [Version] — [Date] ## Pre-Release - [ ] All stories in "Done" column meet acceptance criteria - [ ] QA sign-off on regression test suite - [ ] Performance testing completed (load test results linked) - [ ] Security review completed (if applicable) - [ ] Database migrations tested on staging - [ ] Feature flags configured for gradual rollout - [ ] Rollback plan documented and tested - [ ] Release notes drafted ## Deploy - [ ] Staging deployment successful - [ ] Smoke tests passing on staging - [ ] Production deployment initiated - [ ] Canary metrics monitored (15 min) - [ ] Full rollout completed - [ ] Post-deploy smoke tests passing ## Post-Release - [ ] Monitoring dashboards reviewed (1 hour) - [ ] Release notes published - [ ] Stakeholders notified - [ ] Retrospective scheduled ``` ## Roadmap Planning ### Prioritization Framework: RICE Score each initiative: - **R**each — How many users/customers affected per quarter? - **I**mpact — How much does it move the metric? (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal) - **C**onfidence — How sure are you about reach and impact? (100%=high, 80%=medium, 50%=low) - **E**ffort — Person-months to complete **RICE Score = (Reach x Impact x Confidence) / Effort** Higher score = higher priority. This doesn't replace judgment but makes trade-offs explicit and comparable. ### Quarterly Roadmap Template ```markdown # Q[X] [Year] Engineering Roadmap ## Theme: [One-line description of the quarter's focus] ## Committed (high confidence, resourced) 1. [Initiative] — [Team] — [Goal/Metric] 2. [Initiative] — [Team] — [Goal/Metric] ## Planned (medium confidence, tentatively resourced) 3. [Initiative] — [Team] — [Goal/Metric] 4. [Initiative] — [Team] — [Goal/Metric] ## Exploratory (low confidence, needs scoping) 5. [Initiative] — [Owner for scoping] ## Tech Debt / Platform - [Item] — [Justification] ## Not Doing This Quarter (and why) - [Item] — [Reason] ``` The "Not Doing" section is as important as the committed items — it sets expectations and prevents scope creep. ## Quality Gates These are hard stops. A story cannot enter a sprint, and a sprint cannot start, if any of these gates fail. ### Story Not Ready for Sprint If A story MUST NOT be assigned to a sprint if ANY of these are true: - [ ] **Missing acceptance criteria** — Fewer than 3 scenarios, or scenarios not in Given-When-Then format - [ ] **No error handling scenario** — Story doesn't describe what happens when something goes wrong - [ ] **No edge case considered** — No boundary, race condition, or timeout scenario - [ ] **Missing dependencies** — No list of other stories, APIs, or data required - [ ] **No estimation** — Story has no complexity rating (S/M/L or story points) - [ ] **Unclear scope** — Story is vague ("improve performance", "refactor code") without measurable outcomes - [ ] **No Definition of Done** — Story lacks concrete checklist of what "done" means - [ ] **Unclear success criteria** — How will you know when this story is actually complete? If any are missing, return the story to the backlog with feedback. Do not pull it into sprint planning. ### Sprint Not Ready to Start If The sprint ceremony cannot conclude with commitment if ANY of these are false: - [ ] **All stories estimated** — Every story in the sprint has a complexity rating - [ ] **Sprint goal defined** — Product owner articulated a one-sentence goal for the sprint - [ ] **Team velocity checked** — Compare sprint points to last 3 sprints' velocity; flag if sprint is overcommitted - [ ] **Dependencies mapped** — No critical story blocks another; external dependencies are tracked - [ ] **Risks identified** — Team called out 3-5 potential blockers (API changes, data migration complexity, new vendor integration, etc.) - [ ] **Capacity verified** — Account for planned time off, on-call duties, and meetings; reduce sprint target accordingly - [ ] **Definition of Done agreed** — Team confirms what "done" means for each story - [ ] **No surprises at 3am** — Team has briefly war-gamed the top 2-3 stories to surface unknowns If any are false, resolve them before committing. Do not start a sprint with unresolved questions. ### Commit Decision Framework Before the sprint "goes live," the product owner and tech lead should answer: 1. **Can the team execute?** Are all stories decomposed and dependencies clear? 2. **Is there risk?** What breaks if we deploy without finishing one story? 3. **Is the goal clear?** Can everyone articulate why this sprint matters? 4. **Is the load realistic?** Will the team be heroes at the end, or buried? If the answer to any is unclear, the sprint is not ready. Invest 30 more minutes to fix it. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [camilooscargbaptista](https://github.com/camilooscargbaptista) - **Source:** [camilooscargbaptista/cto-toolkit](https://github.com/camilooscargbaptista/cto-toolkit) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-camilooscargbaptista-cto-toolkit-sprint-planning - Seller: https://agentstack.voostack.com/s/camilooscargbaptista - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.