Agile and Sprints
Agile is a way of building products in short cycles rather than planning everything upfront and building for months before showing anyone the result. Sprints are the individual cycles within Agile. Most modern product teams use Agile because it helps them learn faster and adapt to change.
Why Agile Replaced Waterfall
Before Agile, teams used a method called Waterfall. In Waterfall, the team planned everything first, built everything second, and tested everything last. The problem: by the time the product was done, customer needs had changed. Teams spent 12 months building something nobody wanted anymore.
WATERFALL (Old Way): Plan → Design → Build → Test → Launch (12 months later, customer needs changed) AGILE (Modern Way): [Plan → Build → Test → Learn] → [Plan → Build → Test → Learn] → ... (2 weeks) (2 weeks) Each cycle delivers something real. Team learns and adjusts.
The Core Idea Behind Agile
Agile is built on a simple belief: teams learn more from shipping something real to real users than from planning in a conference room. The shorter the cycle, the faster the team learns and improves.
What Is a Sprint?
A sprint is a fixed period of time — usually 1 or 2 weeks — during which the team builds and delivers a defined set of features or improvements. At the end of each sprint, the team has a working, testable product to show.
Sprint Ceremonies (Key Meetings)
SPRINT PLANNING (Start of sprint, ~2 hours)
PM and team decide which user stories go into this sprint.
Engineers estimate how long each story takes.
↓
DAILY STANDUP (Every day, 15 minutes)
Each person answers:
- What did I finish yesterday?
- What will I do today?
- What is blocking me?
↓
SPRINT REVIEW (End of sprint, ~1 hour)
Team demonstrates what they built to stakeholders.
Real working software, not slides.
↓
SPRINT RETROSPECTIVE (After review, ~1 hour)
Team reflects:
- What went well?
- What went wrong?
- What do we change next sprint?
The Product Backlog
The product backlog is the master list of everything the team might build. It contains user stories, bug fixes, technical improvements, and research tasks — all ranked by priority.
The PM owns the backlog. Their job is to keep it organized, updated, and ranked. At the top of the backlog sit the most important items. At the bottom sit ideas that may or may not happen someday.
Story Points: How Teams Estimate Work
Estimating how long work takes is hard. Teams often use "story points" instead of hours. Story points measure complexity, not time. The team compares each story to a reference point and assigns a relative score.
Common story point scales use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21.
1 point = Very simple (e.g., change a button label) 3 points = Moderate (e.g., add a form with validation) 8 points = Complex (e.g., build a new search filter) 13 points = Very complex (consider splitting into smaller stories)
Over time, the team measures their "velocity" — how many story points they typically complete in one sprint. This helps the PM plan realistically.
Scrum vs. Kanban: Two Agile Approaches
| Factor | Scrum | Kanban |
|---|---|---|
| Time structure | Fixed sprints (1–2 weeks) | Continuous flow, no fixed sprints |
| Planning style | Plan work for the sprint upfront | Pull work as capacity opens |
| Best for | Teams building new features | Teams doing ongoing support or bug fixes |
| Key visual | Sprint board | Kanban board with work-in-progress limits |
The Kanban Board
┌─────────┬─────────────┬────────────┬──────────┐ │ BACKLOG │ IN PROGRESS│ IN REVIEW │ DONE │ ├─────────┼─────────────┼────────────┼──────────┤ │ Story A │ Story C │ Story E │ Story F │ │ Story B │ Story D │ │ Story G │ │ Story H │ │ │ Story I │ └─────────┴─────────────┴────────────┴──────────┘
Work flows from left to right. Teams limit how many items can be "In Progress" at one time to prevent work from piling up.
The PM's Role in Agile
In Agile, the PM (or "Product Owner" in Scrum terminology) makes these key contributions:
- Maintains and ranks the product backlog
- Writes and refines user stories before each sprint
- Attends daily standups to remove blockers
- Accepts or rejects completed work during sprint review
- Represents the customer's voice in all planning decisions
Key Takeaway
Agile and sprints give product teams a rhythm of building, learning, and improving. Short cycles mean faster feedback and fewer costly mistakes. The PM who embraces Agile helps the team stay focused on customer value and avoids the trap of building in isolation for months before discovering what does not work.