What Is Agile and SCRUM for Software Developers?
Purpose
When I joined my first professional development team, I felt lost in meetings. People talked about “sprints,” “standups,” “story points,” and I had no idea what any of it meant. I nodded along, hoping nobody would ask me a question.
This post covers what Agile and SCRUM are, how they work in practice, and what you’ll encounter in a real team environment. By the end, you’ll understand the vocabulary and workflows that most development teams use daily.
What Is Agile?
Agile is a software development philosophy, not a strict process. It started in 2001 when seventeen developers wrote the Agile Manifesto, which values:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThe core idea: build software in small increments, get feedback fast, and adapt.
Agile vs Waterfall
Before Agile, most teams used Waterfall. Here’s how they compare:
WATERFALL AGILE───────────────────────── ─────────────────────────Requirements (months) Sprint 1 (2 weeks) ↓ ↓Design (months) Sprint 2 (2 weeks) ↓ ↓Development (months) Sprint 3 (2 weeks) ↓ ↓Testing (months) Sprint 4 (2 weeks) ↓ ↓Deployment (once) Deploy each sprint
Problem: Feedback comes Benefit: Feedback everyonly at the end 2 weeksIn Waterfall, I spent six months building something nobody wanted. In Agile, I build something small, show it, and adjust. Much better.
What Is SCRUM?
SCRUM is a specific framework that implements Agile principles. Think of Agile as the philosophy and SCRUM as the recipe.
SCRUM Roles
┌─────────────────────────────────────────────────────────────┐│ SCRUM TEAM │├─────────────────┬─────────────────┬─────────────────────────┤│ Product Owner │ Scrum Master │ Developers ││ │ │ ││ • Owns the │ • Removes │ • Build the product ││ product │ blockers │ • Write code ││ • Prioritizes │ • Facilitates │ • Test features ││ backlog │ ceremonies │ • Document work ││ • Accepts/ │ • Shields team │ ││ rejects work │ from noise │ │└─────────────────┴─────────────────┴─────────────────────────┘Product Owner: Decides what to build. They talk to stakeholders, gather requirements, and prioritize the backlog. When I’m confused about a feature, I ask the Product Owner.
Scrum Master: Keeps the process running. They run meetings, remove obstacles, and protect developers from interruptions. Not a manager—a facilitator.
Developers: Build the product. That’s you and me. We estimate work, write code, test, and deliver.
SCRUM Artifacts
Artifacts are documents that track work:
┌────────────────────────────────────────────────────────────┐│ PRODUCT BACKLOG ││ (Everything we might build, prioritized by value) │├────────────────────────────────────────────────────────────┤│ #1 User login via email ││ #2 Password reset flow ││ #3 Export data to CSV ││ #4 Dark mode support ││ #5 Mobile responsive design ││ ...hundreds more... │└────────────────────────────────────────────────────────────┘ │ │ Top items pulled for sprint ↓┌────────────────────────────────────────────────────────────┐│ SPRINT BACKLOG ││ (Work committed for this 2-week sprint) │├────────────────────────────────────────────────────────────┤│ #1 User login via email [3 points] ││ #2 Password reset flow [5 points] ││ #3 Export data to CSV [2 points] │└────────────────────────────────────────────────────────────┘Product Backlog: The master list of everything the product needs. The Product Owner maintains this.
Sprint Backlog: What we commit to finishing this sprint. Only what we can realistically complete.
SCRUM Ceremonies
Ceremonies are scheduled meetings:
┌─────────────────────────────────────────────────────────────┐│ SPRINT CEREMONIES │├─────────────────────────────────────────────────────────────┤│ ││ Sprint Planning (Start of Sprint) ││ └─ What can we deliver? (2-4 hours) ││ ││ Daily Standup (Every day) ││ └─ What did I do? What's next? Blockers? (15 min) ││ ││ Sprint Review (End of Sprint) ││ └─ Demo what we built (1 hour) ││ ││ Sprint Retrospective (End of Sprint) ││ └─ What went well? What to improve? (1 hour) ││ │└─────────────────────────────────────────────────────────────┘The Sprint Cycle
A sprint is a time-boxed period (usually 2 weeks) where the team commits to completing specific work.
SPRINT TIMELINE (2 WEEKS) ┌──────────────────────────────────────────────────┐ │ │Day 1: ┌─────────────────────────────────────────────┐ │ │ SPRINT PLANNING │ │ │ • Review top backlog items │ │ │ • Team estimates story points │ │ │ • Commit to sprint backlog │ │ └─────────────────────────────────────────────┘ │ │Day 2-10: ┌─────────────────────────────────────────┐ │ │ DAILY STANDUP (15 min each morning) │ │ │ • Yesterday: Fixed login bug │ │ │ • Today: Working on password reset │ │ │ • Blockers: Need API key from DevOps │ │ │ │ │ │ Then: CODE, TEST, INTEGRATE │ │ └─────────────────────────────────────────┘ │ │Day 10-11: ┌────────────────────────────────────────┐ │ │ SPRINT REVIEW │ │ │ • Demo working features to stakeholders │ │ │ │ │ │ SPRINT RETROSPECTIVE │ │ │ • What worked: Pair programming │ │ │ • What didn't: Too many meetings │ │ │ • Action items for next sprint │ │ └────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────┘ │ ↓ NEXT SPRINT STARTSDaily Standup Format
The daily standup is quick and structured. Everyone answers three questions:
┌─────────────────────────────────────────────────────────────┐│ DAILY STANDUP ││ (15 minutes max) │├─────────────────────────────────────────────────────────────┤│ ││ Developer 1: ││ "Yesterday I finished the login API endpoint. ││ Today I'm working on error handling. ││ No blockers." ││ ││ Developer 2: ││ "Yesterday I started the password reset UI. ││ Today I'll connect it to the backend. ││ Blocked: Need the API documentation from Team B." ││ ││ Developer 3: ││ "Yesterday I wrote tests for the export feature. ││ Today I'll review Developer 1's PR. ││ No blockers." ││ │└─────────────────────────────────────────────────────────────┘Don’t turn standup into a problem-solving session. Note the blockers, move on. Solve problems after the meeting.
User Stories and Story Points
User Story Format
User stories describe features from the user’s perspective:
┌─────────────────────────────────────────────────────────────┐│ USER STORY FORMAT │├─────────────────────────────────────────────────────────────┤│ ││ As a [type of user] ││ I want [an action] ││ So that [a benefit/value] ││ │├─────────────────────────────────────────────────────────────┤│ EXAMPLES │├─────────────────────────────────────────────────────────────┤│ ││ As a registered user ││ I want to reset my password ││ So that I can access my account if I forget it ││ ││ As an admin ││ I want to export user data to CSV ││ So that I can analyze it in Excel ││ ││ As a new visitor ││ I want to sign up with my email ││ So that I can create an account ││ │└─────────────────────────────────────────────────────────────┘Story Points
Story points estimate effort, not time. We use Fibonacci numbers because uncertainty grows with complexity:
┌─────────────────────────────────────────────────────────────┐│ STORY POINTS │├──────────┬──────────────────────────────────────────────────┤│ POINTS │ EFFORT/COMPLEXITY │├──────────┼──────────────────────────────────────────────────┤│ 1 │ Trivial. Copy a file, fix a typo. ││ 2 │ Simple. Small code change, obvious solution. ││ 3 │ Straightforward. Clear path, some work. ││ 5 │ Moderate. Some complexity, may need research. ││ 8 │ Complex. Uncertain areas, might hit blockers. ││ 13 │ Very complex. Break it down into smaller stories ││ 21 │ Too big. Definitely break down. │└──────────┴──────────────────────────────────────────────────┘Why not use hours? Because I can estimate “this feels like a 5” much better than “this will take 7.5 hours.” Hours lie. Points are relative.
Planning Poker
Teams estimate together using planning poker:
┌─────────────────────────────────────────────────────────────┐│ PLANNING POKER │├─────────────────────────────────────────────────────────────┤│ ││ Product Owner reads story: ││ "As a user, I want to reset my password..." ││ ││ Team discusses: ││ • What about email templates? ││ • Do we need rate limiting? ││ • What about security tokens? ││ ││ Everyone reveals cards simultaneously: ││ ││ Dev 1 Dev 2 Dev 3 Dev 4 ││ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ││ │ 5 │ │ 3 │ │ 5 │ │ 8 │ ││ └───┘ └───┘ └───┘ └───┘ ││ ││ Discuss the spread: ││ • Dev 4: "Why 8? What complexity do you see?" ││ • Dev 4: "We need to handle expired tokens, plus testing" ││ • Dev 2: "Why 3? Seems more complex to me." ││ ││ Re-vote until consensus (usually 5 or 8) ││ │└─────────────────────────────────────────────────────────────┘Working with Jira
Most teams use Jira to track SCRUM work. Here’s what a sprint board looks like:
┌──────────────────────────────────────────────────────────────────────────┐│ SPRINT BOARD: Sprint 23 (Mar 10 - Mar 24) │├────────────────┬────────────────┬────────────────┬────────────────────────┤│ TO DO │ IN PROGRESS │ IN REVIEW │ DONE ││ │ │ │ ││ ┌────────────┐ │ ┌────────────┐ │ ┌────────────┐ │ ┌────────────────────┐ ││ │ LOGIN-42 │ │ │ LOGIN-40 │ │ │ LOGIN-38 │ │ │ LOGIN-35 │ ││ │ Password │ │ │ Email │ │ │ Export CSV │ │ │ User registration │ ││ │ reset │ │ │ validation │ │ │ │ │ │ │ ││ │ ●●●○○ 5pts │ │ │ ●●○○○ 3pts │ │ │ ●●○○○ 3pts │ │ │ ●●●●○ 8pts ✓ │ ││ └────────────┘ │ └────────────┘ │ └────────────┘ │ └────────────────────┘ ││ │ │ │ ││ ┌────────────┐ │ ┌────────────┐ │ │ ┌────────────────────┐ ││ │ LOGIN-43 │ │ │ LOGIN-41 │ │ │ │ LOGIN-36 │ ││ │ Dark mode │ │ │ 2FA setup │ │ │ │ Login page UI │ ││ │ ●●●●● 13pts│ │ │ ●●●●○ 8pts │ │ │ │ ●●●○○ 5pts ✓ │ ││ └────────────┘ │ └────────────┘ │ │ └────────────────────┘ ││ │ │ │ ││ │ │ │ ┌────────────────────┐ ││ │ │ │ │ LOGIN-37 │ ││ │ │ │ │ Dashboard API │ ││ │ │ │ │ ●●●●○ 8pts ✓ │ ││ │ │ │ └────────────────────┘ │├────────────────┴────────────────┴────────────────┴────────────────────────┤│ Sprint Progress: ████████░░░░░░░░░░░░ 21/39 points (54%) ││ Days Remaining: 5 │└──────────────────────────────────────────────────────────────────────────┘Your Typical Jira Workflow
When I pick up a story, here’s my workflow:
1. Move story from TO DO → IN PROGRESS2. Create a git branch: feature/LOGIN-42-password-reset3. Write code, commit with message: "LOGIN-42: Add password reset flow"4. Open pull request, link to Jira ticket5. Move story to IN REVIEW6. Address review feedback7. Merge to main8. Move story to DONEUseful Jira Tips
Filter your tickets:
assignee = currentUser() AND status != DoneSee sprint progress:
sprint in openSprints() AND project = LOGINFind blocked items:
status = "In Progress" AND updated < -3dSummary
Agile and SCRUM can feel overwhelming at first. Let me simplify what matters for you as a developer:
You need to know:
- Sprints are 2-week commitments. Don’t over-promise.
- Standups are 15 minutes. Be brief and honest about blockers.
- Story points are relative estimates, not hours.
- Your Product Owner decides what to build. You decide how to build it.
- Jira tracks everything. Keep your tickets updated.
What actually matters:
- Deliver working code every sprint
- Communicate early when blocked
- Participate in planning—your estimates affect commitments
- Be honest about progress in standups
The process exists to help you ship. When it feels like overhead, push back in retrospectives. That’s what they’re for.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments