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.
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 https://www.scrum.org/ to solve them
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.
The following roles within our SCRUM implementation deserve clarification
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.
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.
The following artifacts are the ones we consider they deserve a detailed explanation.
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:
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
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.
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.
Tell us your idea and we will prepare a proposal