Agile and Scrum - Guide
development agile scrum project-management
What is Agile?
Agile is a philosophy for building software based on one core idea: instead of planning everything upfront and building it all at once (Waterfall), you build in small increments, get feedback, and adapt.
Waterfall vs. Agile
| Waterfall | Agile | |
|---|---|---|
| Approach | Plan everything → Build everything → Deliver | Plan a little → Build a little → Get feedback → Repeat |
| Change | Expensive and disruptive | Expected and welcomed |
| Delivery | One big release at the end | Working software every 1-4 weeks |
| Risk | You find problems late | You find problems early |
| Documentation | Heavy upfront specs | Just enough to be useful |
The key insight: You can’t know everything at the start. Agile accepts this and builds a process around learning as you go.
Agile Principles (The Ones That Matter Most)
The Agile Manifesto has 12 principles. Here are the most practical ones:
| Principle | What It Means in Practice |
|---|---|
| Working software over documentation | A running feature beats a perfect spec. Ship something real. |
| Responding to change over following a plan | Plans are useful, but don’t cling to them when reality shifts. |
| Individuals and interactions over processes | Talk to people. Don’t hide behind tickets and email. |
| Customer collaboration over contract negotiation | Build with users, not just for them. |
| Deliver frequently | Weeks, not months. Small batches reduce risk. |
| Simplicity — maximize work not done | The best feature is the one you didn’t need to build. |
| Reflect and adjust regularly | Retrospectives aren’t optional — they’re how you improve. |
Scrum Framework
Scrum is the most widely used Agile framework. It provides a structured way to do Agile with defined roles, events, and artifacts.
The Sprint Cycle
┌─────────────────────────────────────────────────┐
│ SPRINT (1-4 weeks) │
│ │
│ ┌──────────┐ ┌───────┐ ┌───────┐ ┌──────┐ │
│ │ Sprint │ │ Daily │ │ Dev │ │Sprint│ │
│ │ Planning │→ │Standup│→ │ Work │→ │Review│ │
│ └──────────┘ └───┬───┘ └───────┘ └──┬───┘ │
│ │ │ │
│ └──── repeats daily ───┘ │
│ │
└──────────────────────┬──────────────────────────┘
│
▼
┌─────────────┐
│Retrospective│ → What went well? What to improve?
└──────┬──────┘
│
▼
Next Sprint...
Roles
| Role | Responsibility |
|---|---|
| Product Owner | Decides what to build. Owns the backlog, prioritizes features, represents the user/business. |
| Scrum Master | Facilitates the process. Removes blockers, runs ceremonies, protects the team from distractions. |
| Development Team | Decides how to build it. Self-organizing, cross-functional (3-9 people typically). |
Artifacts
| Artifact | What It Is |
|---|---|
| Product Backlog | The master list of everything that could be built — features, bugs, improvements. Ordered by priority. The Product Owner owns this. |
| Sprint Backlog | The subset of backlog items the team commits to completing this sprint, plus a plan for delivering them. |
| Increment | The working, potentially shippable product at the end of each sprint. Each sprint adds to it. |
Ceremonies (Events)
| Event | When | Duration | Purpose |
|---|---|---|---|
| Sprint Planning | Start of sprint | 1-2 hours | Pick items from backlog, define sprint goal, break into tasks |
| Daily Standup | Every day | 15 min max | Three questions: What did I do? What will I do? Any blockers? |
| Sprint Review | End of sprint | 1 hour | Demo the increment to stakeholders, collect feedback |
| Sprint Retrospective | After review | 1 hour | Team reflects: What went well? What didn’t? What to change? |
Kanban (Quick Overview)
Kanban is another Agile approach, simpler than Scrum. Instead of time-boxed sprints, work flows continuously through stages.
Kanban Board
┌───────────┬───────────┬───────────┬───────────┐
│ Backlog │ To Do │ Doing │ Done │
├───────────┼───────────┼───────────┼───────────┤
│ Feature C │ Feature B │ Feature A │ │
│ Bug #42 │ │ Bug #39 │ │
│ Feature D │ │ │ │
└───────────┴───────────┴───────────┴───────────┘
Scrum vs. Kanban
| Scrum | Kanban | |
|---|---|---|
| Cadence | Fixed sprints (1-4 weeks) | Continuous flow |
| Roles | Defined (PO, SM, Team) | No prescribed roles |
| Planning | Sprint planning sessions | Pull when ready |
| WIP Limits | Sprint capacity | Explicit per-column limits |
| Best for | Teams with regular release cycles | Teams with unpredictable incoming work |
For solo developers, Kanban is often more practical — less ceremony, more flexibility.
Key Terms Cheat Sheet
| Term | Definition |
|---|---|
| Epic | A large body of work that can be broken into multiple stories |
| Story (User Story) | A single feature or requirement from the user’s perspective |
| Task | A technical step needed to complete a story |
| Story Points | Relative estimate of effort (not hours) — often Fibonacci: 1, 2, 3, 5, 8, 13 |
| Velocity | How many story points a team completes per sprint (used for forecasting) |
| Burndown Chart | Graph showing remaining work vs. time in a sprint |
| Definition of Done | Agreed criteria for when work is truly complete (coded, tested, documented) |
| WIP (Work in Progress) | Number of items being actively worked on simultaneously |
| Blocker | Something preventing progress on a task |
| Spike | A time-boxed research task to reduce uncertainty before committing to a story |
Applying to Solo / LLM Projects
You don’t need a Scrum Master or daily standups when you’re a team of one (plus an LLM). But the principles behind these practices still apply.
What to Adopt
| Practice | Solo Adaptation |
|---|---|
| Product Backlog | Maintain a prioritized list of features/tasks (GitHub Issues, a markdown file, or a project board) |
| Sprints | Work in 1-week cycles. Pick 3-5 items at the start, review progress at the end. |
| Kanban Board | Use a simple board (GitHub Projects, Trello, or even a markdown table) with Backlog → Doing → Done |
| Daily Check-in | Start each session by reviewing: Where did I leave off? What’s next? Any blockers? |
| Retrospective | Weekly: What went well? What didn’t? What should I change about my LLM workflow? |
| Definition of Done | Define it per task — “done” means working, tested, and committed — not just “the AI generated code” |
| Spikes | Before building something complex, spend a focused session researching with the LLM first |
| WIP Limits | Limit yourself to 1-2 active tasks. Context switching kills momentum. |
LLM-Specific Tips
- Use your backlog as session context. Paste your current sprint items at the start of an LLM session so it knows the bigger picture.
- Retrospect on your prompts. If the LLM keeps producing bad output, the problem is usually in your requirements (user stories / acceptance criteria), not the model.
- Break epics into stories before coding. Ask the LLM to help decompose a large feature into small, independently shippable stories.
- Version your planning docs. Keep your PRD, backlog, and sprint notes in the repo. They’re as valuable as the code.
Suggested Solo Workflow
1. PLAN Write a mini-PRD, break into stories (see PRD page)
2. SPRINT Pick 3-5 stories for the week
3. BUILD Work through stories one at a time with LLM
4. REVIEW At week's end: What shipped? Demo to yourself.
5. RETRO What worked? What to change? Update backlog.
6. REPEAT