Scrum and agile methodology

Vinícius Machado de Souza — Tue, 08 Oct 2024 13:24:28 +0000

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:

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.
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.
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!

GitHub: learning about the feature called Issues☕

Vinícius Machado de Souza — Fri, 20 Sep 2024 13:07:31 +0000

What is an "issue" about?

Issues are used to track bugs and suggest improvements, providing a step-by-step control of our project. To reference a commit to an issue, simply add #[issue number] after the sentence in the commit command. Example:

git commit -m “my example #1”

To close an issue, the command used is:

git commit -m “issue closed closes #1”

To indicate that the issue has been fixed, we use the following command:

git commit -m "issue fixed fixes #1"

Step-by-step guide to using Issues:

1.Access a GitHub repository where the "Issues" feature is enabled.

2.Go to the "Issues" tab located next to "Code" to view the existing Issues.

3.Create a new Issue by clicking the "New Issue" button next to "Labels" and "Milestones."

4.Now you have access to various tools for creating an Issue, starting with the basics: a title and a detailed description of the topic being addressed.

5.On the side, there are tools to help manage Issues. First, there’s "Assignees," which refers to the people responsible for working on the Issue. Then, "Labels," which act as tags to categorize different types of Issues. "Milestone" is essentially a goal or target to be achieved. In the "Development" section, you’ll see branches and pull requests related to that Issue.

6.Now that the Issue has been created, comments can be added to allow team members to collaborate and resolve the Issue. Below, if you are the owner or a collaborator of the repository, you can close the Issue in two ways: "Close as completed," which means the issue was resolved, or "Close as not planned," meaning the issue wasn’t resolved or something else happened.

7.After creating the Issue, there are some additional options if you are the owner or a collaborator of the repository. "Lock conversation" removes the permission for other users to comment on the Issue. "Pin issue" allows you to pin up to three Issues to the top. "Transfer Issue" moves the Issue to another repository without deleting it from the current one. "Delete Issue" completely removes the Issue instead of simply closing it.

If you liked this post and it helped you better understand a GitHub feature, how about checking out other posts about Git and GitHub? Take a look at the link ahead! Forks in GitHub

DEV Community: Vinícius Machado de Souza