Glossary of Terms and Good Practices

Although we do not intend to explain SCRUM in depth, in this space we will clarify several points that will surely be of use or interest in case of working with our agile development teams.

What is Scrum?

Scrum: is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

If you have conceptual doubts or want more information, I suggest going to to solve them

The Agile Principles

We thought it appropriate to include in this article what for us are the TOP 5 of the 12 Agile principles, so that our philosophy is better understood.

  1. Deliver Value Faster: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome Change: Welcome the changes in requirements, even at the end of projects. Agile processes make the most of that change for the customer's competitive advantage.
  3. Work Together Daily: The product owner, the scrum master and the entire scrum team must work together daily throughout the project and with the same objective.
  4. Working Software is Key: Working software is the main measure of progress.
  5. Simplicity: The art of maximizing the amount of work not done is essential.

Key Roles

The following roles within our SCRUM implementation deserve clarification

Product Owner

It is the person who knows the product, knows what he needs, what is really important and what is not. Their main responsibility is to transmit to the team what he wants to be built, providing all the necessary information to carry out the development.

More information

Scrum Master

In addition to being a “facilitator” for SCRUM to be executed as it should be, he will be the main point of contact with the product owner (the client) to help him with whatever is necessary.

More information


The following artifacts are the ones we consider they deserve a detailed explanation.

User Story

It is a very high-level definition of a requirement. It should contain enough information so that developers can estimate the effort to implement it.

A good user story should consider the three “Ws” (who, what, why). That is, who will do something, what will they do and why. In addition, you must meet the INVEST criteria:

  • Independet: the user story must be self-explanatory; it must not depend on other user stories.
  • Negotiable: to avoid including too much detail, so that user stories are flexible and can be modified.
  • Valuable: user stories should bring some value to the end user.
  • Estimable: you must be able to estimate the resources needed to complete each user story.
  • Scalable: make user stories simple, so they can be commissioned and prioritized.
  • Testable: explain the verification and approval criteria, so that the team knows and applies them when a story is complete.
Checklist to accept a User Story
scrum - user stories

It is a very simple case, but I think it clarifies the concepts explained above.

As a start-up founder, I want to be able to create an account on the XYZ site, so that I can join the community of investors and mentors.

       Criteria of acceptance

  1. To be able to create an account manually (by completing the sign-up form)
  2. Create an account via Google
  3. Create an account via Facebook

Product Backlogs

It is nothing other than user stories transformed into a prioritized list of deliverables that must be implemented through the development process. A product backlog item (PBI) is a single item within that list. It must contain all the necessary information so that the team can eventually include it within an iteration (transformed into a sprint backlog).

It might at first seems like it is the same as a user story, but it is not. The latter goes beyond a particular change or requirement. It puts the user at the center and describes a feature of the system from his point of view.

Sprint Backlog

During the Planning meeting, the PBIs that will be part of the next sprint are selected and divided into one or more sprint backlog item (SBI). Being simplistic, it is nothing more than a PBI within a sprint. Actually, it’s a bit more, because that SBI needs to have a higher level of detail. Furthermore, one PBI can give rise to several different SBIs.


They are nothing more than meetings with different participants and designed for very specific purposes. To be clear, not everything that takes place in these meetings will be discussed, but the purpose of the meetings will be made clear.


In this meeting, which occurs prior to the start of a sprint, the PBI that will be developed in it are selected and transformed into SBI.


In this meeting, which takes place during the first days of the start of an iteration, the following PBIs to be developed in the next sprint (not the current one) are analysed and refined. That is, they are lowered to a sufficient level of detail in order to be developed later.


This daily meeting is made to see what was done the day before, what will be done on the current day and the impediments that may exist.


In this meeting, which takes place after the completion of an iteration, the result of the iteration is presented to the product owner.


Main Features

Multidisciplinary and self-organized teams

Agile development

Increase team motivation

Client integrated in the team

Quick feedback of the product in development

Flexibility in incorporating changes

Reduction in the final delivery time of the project

Contact Us

Tell us your idea and we will prepare a proposal