DEV Community

Cover image for Scrum and agile methodology
Vinícius Machado de Souza for LEDS

Posted on • Edited on

Scrum and agile methodology

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."
a


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

a


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.

a

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
a

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
a

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!

Top comments (3)

Collapse
 
thescrummastercouk profile image
TheScrumMaster

This is a nice overview, but a few minor corrections are required.

  • It is Scrum (not SCRUM)
  • It is Developers (not Development team)
  • It is self-management (not self-organisation)
  • A timebox is not a deadline. The timebox for the Sprint is intended to limit the planning horizon, scope, risk and ensure regular inspection and adaptation.
  • The correct names for the Scrum events are - Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
  • The questions listed are not mandatory at the Daily Scrum. The Developers can structure it however they wish as long as they use it to inspect progress toward the Sprint Goal and adapt the Sprint Backlog (their plan) as necessary.
  • User stories are an optional practice.
  • The (other) four events happen within the Sprint
  • Planning Poker is an optional practice (as you rightly mention)

I have been using Scrum for 20 years and have taught 25,000 people how to use it.
Try our free Ultimate Scrum eLearning Course to learn more:
goto.thescrummaster.co.uk/DevToUlt...

Collapse
 
machadovsouza29 profile image
Vinícius Machado de Souza

Thank you very much for the comment! I made changes based on what you said, and I appreciate you sharing your knowledge! I will check out your course.

Collapse
 
jgmluiz profile image
José Guilherme Maragno Luiz

It's fascinating to see how Scrum has evolved over the years and remains a powerful framework for many development teams. The way Scrum integrates collaboration, value prioritization, and rapid iterations is highly effective. However, like any approach, there is always room for innovation.

This reminds me of how the CORE Framework aims to be the "heir" to the main methodologies, including Scrum, Agile, Lean, and even DevOps. CORE strives to maintain the essence of these frameworks, but with a more flexible and adaptable approach, allowing teams to incorporate practices that work best for them without losing focus on outcomes.

While Scrum is heavily focused on its sprint cycle and backlog, CORE introduces a more holistic view that better integrates business strategy, technology, and continuous processes. For instance, CORE adopts Lean elements to optimize flows, Agile for rapid adaptation, and DevOps for automation and continuous delivery. All of this in one framework that respects collaboration and self-management but is even more adaptable to the particularities of each team.

If you're already a Scrum enthusiast and curious to expand your horizons, it might be worth exploring this new approach. Who knows, we might discover even more effective ways to develop products?