Nowadays in the IT industry, wherever you go, you hear the buzzwords "Agile" and "Scrum." Everyone is talking about them. But what exactly is Agile, and how does Scrum relate to it?
What is Agile?
Agile is a methodology initiated by a group of software developers who came together to discuss how to improve the software development process and solve traditional problems. This discussion gave birth to the Agile approach. (If you are interested, you can read more about its history here).
Agile is built upon 4 core values:
-
Individuals and interactions over processes and tools: Focusing on human communication and collaboration rather than strictly following set processes and tools.
-
Working software over comprehensive documentation: Prioritizing the delivery of functional software over creating massive amounts of exhaustive documentation.
-
Customer collaboration over contract negotiation: Emphasizing working closely with the customer rather than merely negotiating terms to meet a contract.
-
Responding to change over following a plan: Embracing and adapting to changes rather than rigidly sticking to an initial plan.
How Scrum Fits In
Scrum is a practical framework that upholds and respects the 4 core values of Agile. It is easy to understand because it provides clear guidelines, but it is notoriously difficult to master due to the complexities in its real-world application.
Think of it like sports: Waterfall is like a relay race, where you have to wait for one person's part to finish before moving forward. Scrum, on the other hand, is like rugby. The whole team is on the field playing together, sharing the single goal of getting the ball across the finish line.
For the most standard guidelines, you can study the official Scrum Guide.
Scrum is built on the foundation of Empiricism—the concept that knowledge comes from experience and making decisions based on what is actually observed and understood. This relies on three main pillars:
-
Transparency: Everything must be clear and visible. Everyone should immediately understand what is happening, what is being worked on, and what needs to be done.
-
Inspection: There must be continuous checks to ensure that the Scrum Artifacts are aligning with the Sprint Goal.
-
Adaptation: If an inspection reveals a problem that might prevent the team from delivering the work, adjustments must be made immediately—whether to the process or the product—to ensure delivery as quickly as possible.
The Scrum Team
The team consists of 3 distinct roles:
-
Product Owner (PO): The person who understands the product and requirements best. The PO's job is to continuously prioritize the work for the Development Team. They constantly communicate with customers or the CEO to discuss requirements and must be able to guide and advise the client.
-
Development Team: The people who continuously build the product according to the agreed-upon "Definition of Done." Characteristics of this team include: they manage their own work (no one forces them), team members can cross-train and cover for each other, there are no specific titles (Dev, QA, BA, SA, Tester, UX, UI—everyone is simply the "Dev Team"), there are no sub-teams, and accountability belongs to the team as a whole. Ideally, the team should not exceed 9 people (though locally, it's often stretched to 10–12).
-
Scrum Master (SM): The person who continuously supports both the PO and the Dev Team, ensuring they can work smoothly and follow the Scrum framework correctly.
Scrum Events
-
The Sprint: The timebox during which the Scrum Team works to create a product Increment. If issues arise, the Dev Team must notify the SM for help, or the PO if there are requirement issues, so decisions can be made. A Sprint must not exceed 1 month.
-
Sprint Planning: The time when the Dev Team selects items to work on during the Sprint to meet the agreed "Done" criteria. They also define the Sprint Goal (e.g., "Build the Authentication Service"). This is timeboxed to a maximum of 8 hours for a 1-month Sprint.
-
Daily Scrum: A daily 15-minute meeting for the Dev Team. The goal is to inspect progress and ensure everyone is working smoothly. It is often guided by 3 questions: What did you do yesterday? Are there any blockers? What will you do today? (Though these specific questions are optional).
-
Sprint Review: The time when the Dev Team presents the completed work to the PO, clients, or stakeholders. The PO explains the Product Backlog (what is done and what isn't). The Dev Team then demonstrates the working software and gathers feedback from attendees (clients, marketing, etc.). This is timeboxed to a maximum of 4 hours for a 1-month Sprint.
-
Sprint Retrospective: The time for the Scrum Team to discuss the past Sprint—what went wrong, what went well, and what to improve next time. They should identify root causes of problems and find solutions. During this time, the team also updates their Definition of Done (DoD). This is timeboxed to a maximum of 3 hours for a 1-month Sprint.
Scrum Artifacts
-
Product Backlog: The master list of all work needed for the product. The PO must keep this prioritized (most important at the top). To ensure everyone understands it, the team conducts Product Backlog Refinement (taking up no more than 10% of Sprint capacity). Refinement involves breaking down tasks, adding details, or drafting UI screens so the team knows exactly what a backlog item entails. These are often written as User Stories (e.g., "As a member user, I want to log into the dashboard using my Facebook account, so that I can see the dashboard.").
-
Sprint Backlog: The list of items selected for the upcoming Sprint. The Dev Team pulls these from the Product Backlog during Sprint Planning.
-
Increment: The fully functional piece of software produced in the current Sprint, integrated with all previous Sprints. It must be in a usable state, ready to be released whenever the PO decides.
-
Definition of Done (DoD): A shared agreement on what needs to be completed for a backlog item to be considered truly finished (e.g., API documentation created, ERD updated, TDD applied, Automated Tests passed). The Dev Team must always keep the DoD in mind, especially when selecting work during Sprint Planning.
Putting It All Together
Based on the standard process diagram from Scrum.org, the flow starts with the Product Backlog. During Sprint Planning, the Dev Team selects items to form the Sprint Backlog, and the Sprint begins. Every day, the team holds a Daily Scrum to inspect progress and surface issues. At the end, a Sprint Review is held to present the Increment, which is ready to be delivered to users whenever the PO deems fit. Finally, a Sprint Retrospective is held to analyze the good, the bad, and areas for improvement. Meanwhile, Refinement happens continuously as needed by the PO (capped at 10% of the Dev Team's time).
Looking at the theory, it's easy to understand what needs to be done at each step. In reality, however, implementation is incredibly difficult. Real-world work is full of chaotic variables: the Dev Team failing to finish because they overcommitted during Planning, internal team conflicts ruining the work atmosphere, the PO misunderstanding requirements, mid-Sprint changes being demanded, and much more.
Next time, I will talk more about these common problems. Let's share our experiences—what challenges have you faced when trying to implement Scrum?
