What is SCRUM?

Scrum is not a methodology, it is a framework. This means that Scrum won't tell you exactly what to do, but rather it will serve as a "path" to help you achieve your goal.

• SCRUM has 3 basic roles:

1. Scrum Master: The guardian of the process. Responsible for ensuring the process runs smoothly by removing obstacles that hinder the team's productivity, organizing, and facilitating meetings. It is essential for the Scrum Master to have a deep understanding of Scrum.

2. Product Owner: The central figure with leadership authority over the product. Decides which products and features will be developed and in what order. It's their responsibility to communicate to the participants what the Scrum team aims to achieve in the project, and they prioritize the items in the Product Backlog.

3. Developers: Comprises all developers and other professionals directly involved in the product's development. They hold a role in Scrum just as important as the others, as they are responsible for turning the project into reality.

"Build the right thing. Build it the right way. Build it fast."

Scrum Principles

• Empirical process control: Observation and experimentation. Through transparency, inspection, and adaptation, the process is carried out flexibly.

• Self-management: Everyone is responsible for the project.

• Collaboration: No one has climbed Mount Everest alone.

• Value-based prioritization: Focus on delivering the most valuable items to the client.

• Timebox: Exists with the purpose of setting a time frame that encompasses the entire Sprint process. Ideally, a sprint should last between 1 to 4 weeks. If for any reason a task cannot be delivered, it will be moved to the next sprint. This prevents the "student syndrome" — if you give someone 4 hours to complete a task that could be done in 1 hour, they will procrastinate for 3 hours and finish it in the last hour. Therefore, it is crucial to establish boundaries.

• Iteration and increment: Scrum focuses on value delivery. Its stages repeat through sprints, and the results are incrementally based on the client's highest needs.

• Basic Scrum Events

Daily Scrum
Sprint Planning
Sprint
Sprint Review
Sprint Retrospective

Daily Meetings

Every day, there are meetings of approximately 15 minutes where the team seeks to assess whether the project's progress is aligned with the Sprint Goal or if it is necessary to adapt the Sprint Backlog to meet the expected objective. The developers can structure this meeting as they see fit, and below are three questions that are not mandatory but can help guide the meeting process:

What did I do yesterday to help the team reach the sprint goal?

What will I do today to achieve the sprint goal?

Is there any impediment preventing me or the team from reaching the goal?

Product Backlog

It is a list of features to build the product, ordered by priority by the product owner. It consists of short statements that describe what the customer wants the product to do. These statements can be referred to as features or user stories. A Product Backlog consists of:

Feature or User Story: describes a desired functionality for the product.

Importance: describes how important the functionality is.

Estimate: describes how difficult it is for the team to implement.

• How to create a product backlog?

Scrum doesn't tell us how to create a product backlog, only that we must have one. However, to make it easier, here are some steps for its creation:

• Understand the partner's problem
• Write the user stories
• Relate the user stories
• Prioritize the user stories
• Estimate the difficulty of the user stories

This is one of the most challenging stages of a project. To do this, we can use the following techniques:

• Interviews
• Questionnaires
• Observation
• Prototyping
• Investigation
• User journey
• Other techniques to understand the partner's/client's problem

• Paper Prototyping

To help understand the user, a very good technique is Paper Prototyping (Drawing a prototype on paper). This is a brainstorming, design, creation, communication, and interface testing technique that uses paper and pen to understand user needs. This technique can be used to design websites, software, mobile devices, and hardware.

Sprints

A Sprint is a time period during which one or more items from the product backlog are selected to be developed and delivered to stakeholders in order to add value to the project. It is important for sprints to follow a predefined timebox, typically lasting between 1 to 4 weeks, depending on what is set as the final product.

What happens in each day of the Sprint

Before the start of a sprint, a sprint planning meeting is held based on what needs to be delivered as the final product. This meeting is called "sprint planning," where the sprint backlog is created. Based on the team's capacity, it is determined how many features can be fully developed within the sprint timeframe. Among the many methods that exist, one particularly interesting one that can be used for this is Planning Poker.

Planning Poker Cards

Planning Poker works as follows: the development group meets to discuss the candidate user stories to be selected for development in the current sprint. The team members each draw a card with a number that represents the difficulty they perceive in developing that feature— the lower the number, the less complex; the higher the number, the more complex. The team members who played the lowest and highest cards are selected to speak, and they seek to reach a consensus on the difficulty of that user story. This ensures that everyone is involved in the development process and also makes it more agile.

It’s important to note that these features follow the level of importance recorded by the product owner in the product backlog. At the end of the sprint, there are two additional key activities:

Sprint review: This is a meeting held right after the end of a sprint cycle, with the product owner present to validate whether the product being delivered meets their needs.

Sprint Retrospective: This is a meeting with only the development team members to evaluate the pros and cons of the development cycle in question.

Want to follow more content about agile methodologies? Follow LEDS!