Agile Concepts

7 minute read

Agile Fundamentals

Agile is an iterative approach to software development and project management that emphasizes flexibility, collaboration, and customer satisfaction. The Agile Manifesto (2001) defines four core values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum Framework

Scrum is the most popular Agile framework, designed for teams of 3-9 members working in time-boxed iterations called Sprints.

Scrum Roles

Product Owner (PO): Owns the product backlog, prioritizes work, defines acceptance criteria
Scrum Master (SM): Facilitates ceremonies, removes impediments, coaches the team
Development Team: Cross-functional team that delivers the increment (typically 5-7 members)

Scrum Artifacts

Epic

Large body of work that can be broken down into smaller user stories. Epics typically span multiple sprints and represent major features or initiatives.

Example: “Implement user authentication system”
Timeline: Multiple sprints (weeks to months)

User Story

A small, valuable piece of functionality written from the end-user perspective.

Format: “As a [user type], I want [goal] so that [reason]”
Example: “As a user, I want to reset my password so that I can regain access to my account”
Size: Should be completable within one sprint

Task

A technical piece of work required to complete a user story.

Example: “Create database migration for password reset tokens”
Size: Few hours to 2 days

Spike

A time-boxed research or investigation activity to answer a question or gather information.

Purpose: Reduce technical uncertainty, explore solutions
Example: “Research best OAuth 2.0 libraries for our tech stack”
Timeline: Usually 1-3 days, always time-boxed

Bug

A defect or issue in existing functionality that needs to be fixed.

Technical Debt

Code that needs refactoring or improvement to maintain system quality.

Story Points vs Hours

Story Points (Recommended by Scrum Guide):

Relative measure of effort, complexity, and uncertainty
Common scales: Fibonacci (1, 2, 3, 5, 8, 13, 21) or T-shirt sizes (XS, S, M, L, XL)
Focus on relative sizing, not absolute time

Hours (Traditional approach):

Absolute time estimates
Less preferred in Agile due to variability and estimation difficulties

Agile Ceremonies (Events)

Sprint

What: Fixed time-box (iteration) for completing work

Duration: 1-4 weeks (2 weeks is most common in industry)
Original Recommendation: 2-4 weeks (Scrum Guide)
Output: Potentially shippable product increment

Sprint Planning

What: Team plans the work for the upcoming sprint

Duration: Max 8 hours for 4-week sprint (typically 2-4 hours for 2-week sprint)
Participants: Entire Scrum Team
Goals:
- Define Sprint Goal
- Select items from Product Backlog
- Create Sprint Backlog with detailed tasks
When: First day of the sprint

Daily Standup (Daily Scrum)

What: Brief daily sync to inspect progress and adapt plan

Duration: 15 minutes (time-boxed)
Participants: Development Team (PO and SM optional)
Format: Each team member answers:
1. What did I do yesterday?
2. What will I do today?
3. Are there any impediments?
When: Same time every day
Industry Practice: Often happens in morning (9-10 AM)

What: Review and prepare backlog items for future sprints

Duration: ~10% of sprint capacity (2-4 hours per 2-week sprint)
Participants: PO, SM, and Development Team members
Goals:
- Add details, estimates, and acceptance criteria
- Break down large items
- Re-prioritize based on value
When: Mid-sprint, ongoing activity (not an official Scrum event but widely practiced)

Estimation Techniques

Planning Poker

What: Collaborative estimation technique where team members independently estimate story points

Process:
1. PO presents user story
2. Team discusses and asks questions
3. Each member selects a card (Fibonacci: 1, 2, 3, 5, 8, 13, 21)
4. All reveal cards simultaneously
5. Discuss differences (especially highest and lowest)
6. Re-vote until consensus
Benefits: Reduces anchoring bias, encourages discussion, builds shared understanding

Story Pointing

What: Assigning relative effort estimates to user stories

Factors Considered:
- Complexity: How difficult is the work?
- Uncertainty: How much is unknown?
- Effort: How much work is involved?
Scale: Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) or T-shirt sizes (XS, S, M, L, XL)
Reference Story: Teams often use a well-understood story as baseline (e.g., “Login is a 5”)

The Three Amigos

What: Collaboration between three perspectives before development begins

Who: Product Owner (Business) + Developer (Technical) + Tester (Quality)
When: During backlog refinement or before sprint planning
Goals:
- Clarify requirements and acceptance criteria
- Identify edge cases and test scenarios
- Discuss technical approach
- Ensure shared understanding
Duration: 30-60 minutes per story
Output: Well-defined story with clear acceptance criteria and test cases

Parking Lot

What: A place to capture off-topic discussions or issues that arise during meetings

Purpose: Keep meetings focused while acknowledging important topics
Process:
1. Write item on parking lot (board, doc, or backlog)
2. Continue with meeting agenda
3. Address parking lot items after meeting or in appropriate forum
Common Uses: New ideas during sprint planning, technical discussions during standup, impediments that need separate attention

Bullpen

What: Open workspace arrangement where team members sit together

Purpose: Facilitate communication, collaboration, and osmotic learning
Characteristics:
- Co-located team members
- Minimal barriers between team members
- Easy to overhear conversations (information radiators)
- Quick ad-hoc discussions
Modern Practice: With remote work, “virtual bullpen” through always-on video/chat channels

Sprint Review (Demo)

What: Inspect the increment and adapt the Product Backlog

Duration: Max 4 hours for 4-week sprint (typically 1-2 hours for 2-week sprint)
Participants: Scrum Team + Stakeholders
Goals:
- Demo completed work
- Gather feedback
- Discuss what’s next
When: Last day of sprint (or second-to-last day)

Sprint Retrospective (Retro)

What: Team reflects on process and identifies improvements

Duration: Max 3 hours for 4-week sprint (typically 1-1.5 hours for 2-week sprint)
Participants: Scrum Team only
Goals:
- What went well?
- What didn’t go well?
- What will we improve next sprint?
When: After Sprint Review, before next Sprint Planning
Industry Practice: Action items are tracked and reviewed

Typical 2-Week Sprint Timeline

Week 1:
- Monday 9:00 AM: Sprint Planning (2-3 hours)
- Tuesday-Friday 9:00 AM: Daily Standup (15 min)
- Wednesday 2:00 PM: Backlog Refinement (2 hours)

Week 2:
- Monday-Thursday 9:00 AM: Daily Standup (15 min)
- Thursday 2:00 PM: Sprint Review (1-2 hours)
- Friday 9:00 AM: Sprint Retrospective (1-1.5 hours)
- Friday 11:00 AM: Next Sprint Planning (2-3 hours)

Scrum Metrics

Velocity

Average story points completed per sprint over time. Used for capacity planning.

Industry Practice: Calculate as rolling average of last 3-5 sprints

Burndown Chart

Shows remaining work in the sprint over time. Helps track if team is on track.

Burnup Chart

Shows completed work over time. Better for tracking scope changes.

Sprint Commitment vs Completion

Percentage of committed work actually completed. Target: 80-100%

Scrum Board

A visual representation of work status, typically with columns:

To Do: Work selected but not started
In Progress: Currently being worked on
Review/Testing: Completed but awaiting validation
Done: Meets Definition of Done

Industry Practice: Many teams add additional columns like “Code Review”, “QA Testing”, or “Blocked”

A Scrum board is visible in both:

Plan mode: Backlog view for future work
Work mode: Active Sprint view for current work

Definition of Done (DoD)

A shared understanding of what “complete” means for a user story or increment.

Typical DoD checklist:

Code written and reviewed
Unit tests written and passing (>80% coverage)
Integration tests passing
Documentation updated
Acceptance criteria met
Deployed to staging environment
Product Owner accepted

Jira Board

JIRA Agile (Jira Software) is a popular tool for Scrum teams.

Everything in JIRA is called an issue
- Types: Epic, Story, Task, Bug, Spike, Sub-task
Each issue can be assigned, estimated, and tracked
JIRA tracks Burndown Chart, Velocity Chart, Sprint Reports

Two Agile modes:

Scrum: For teams with fixed-length sprints and defined ceremonies
Kanban: For continuous flow, no sprints, WIP limits

Jira Concepts

Epics: Like buckets grouping similar user stories

Versions: Software releases with new features (used for release planning)

Components: Architectural areas or team boundaries

Labels: Flexible tagging for additional categorization

Kanban vs Scrum

Aspect	Scrum	Kanban
Iterations	Fixed sprints	Continuous flow
Roles	PO, SM, Dev Team	No prescribed roles
Ceremonies	5 ceremonies	Optional standup
Changes	No mid-sprint changes	Changes anytime
Metrics	Velocity, Burndown	Lead time, Cycle time
Best For	Fixed deadlines, predictable delivery	Continuous delivery, support

Industry Best Practices

Keep sprints consistent: Don’t change sprint length frequently
Limit WIP (Work In Progress): Focus on finishing over starting
Definition of Ready: Ensure stories are ready before Sprint Planning
Protect sprint scope: Avoid adding work mid-sprint
Time-box everything: Respect ceremony time limits
Automate: CI/CD pipelines for faster feedback
Co-location or video: Face-to-face communication when possible
Sprint Goal: Every sprint should have a clear, singular goal
Team stability: Keep teams together for at least 3-6 sprints
Continuous improvement: Actually implement retro action items