Scrum is a framework focused around the development of a product, a way of guiding teams and organizing the way in which products are developed.
During times of constant technological advances and in which learning is valued above all else, Scrum is a great solution for constant adaptation.
It is important to remember that Scrum works as a framework and not as a methodology, which is a commonly held misbelief.
It is said that Scrum does not prescribe, it does not tell us “how” to do things, but only tells us what should be done to obtain a product incrementally.
Scrum is not a project management method, but rather a framework focused around the development of a product, which measures the success of said development based on the value that is added to the product over time.
The Scrum Ceremonies
The Scrum framework is organized into five events or ceremonies that guide the development of a product empirically, as the team learns from the experiences of each cycle and adapts the work process as and when necessary.
These five ceremonies are:
Refinement of the Product Backlog
The objective of this activity is to work on the functionalities that the Product Owner, based on the needs of the business, wants and/or needs to develop in the next work sprint.
Through this activity it is possible to obtain more detail, clarity, and definition of what is to be discussed and reviewed later in the Sprint Planning Meeting.
Sprint Planning Meeting
In this ceremony the Scrum team formally defines what will be done during the Sprint that is being planned. In this meeting, the business needs supplied by the Product Owner, the Product Backlog, the agreements that arose in the Retrospective of the previous sprint, and the abilities/availability of the team are all taken into consideration.
The objective of the sprint must be explicitly expressed and is what will guide the team throughout the duration of this stage. Knowledge of the objective also affords the team a certain level of autonomy when making decisions.
Importantly,
the Sprint objective should not change during this work stage.
Planning Stages
When planning, there are two stages that must be considered:
- Defining “what” will be worked on
- Defining “how” the objective will be achieved
In practice, what should happen is that the Product Owner presents the needs and priorities of the business to the Team Members, and the technical feasibility and fulfillment capacity are analyzed and reviewed.
Then it is agreed upon together which of the needs presented by the Product Owner will be fulfilled. From this agreement arises the commitment of the team to what is going to be delivered at the end of the sprint.
In the second stage of Planning the team members discuss in detail “how” this will be achieved. What needs to be done is technically analyzed, tasks are defined, and the Product Owner does not need to be present.
At this point it is important to emphasize that the refinement meeting is useful so that planning does not take up too many working hours.
The maximum duration of the planning stage is defined as 8 hours for a one-month sprint.
In this meeting there must be debate and discussion, and there must be an agreement on what is to be developed during the Sprint; the team must be clear on what it intends to do before committing to doing so.
There should be no imposition by the Product Owner, or the Scrum Master, or any other takeholder.
Daily meetings
In these meetings the team members monitor the progress of the Sprint.
It is a 15-minute-maximum meeting where the Team Members present the status of the work that has been completed and that remains outstanding, as agreed for the Sprint.
Each one tells the team what task they are going to continue with until the next daily meeting and if they have any problems moving forward.
Some interesting points to highlight:
- In this meeting the team is not accountable to the Scrum Master.
- The objective of the daily meeting is to eliminate or attend to any type of problem that threatens the achievement of the sprint objective in a timely manner. In this way inconveniences are controlled and monitored daily in Scrum.
- It is a meeting to make problems or inconveniences that are preventing the achievement of the Sprint objective “visible". It is not a meeting to "solve" these problems or challenges.
- So, when reviewing the impediments on a daily basis, it could be said that this is a space where the threats that could prevent the team from reaching the objective defined for the sprint are managed.
Product Reviews
This event is held at the end of the sprint and
its objective is to present the project stakeholders (whoever the Product Owner deems necessary, invited by the Product Owner) with the results of the work that has been carried out during the Sprint.
This meeting is one of the 3 inspection moments within the Scrum framework
, as the product is inspected in order to obtain feedback from the stakeholders.
Usually, this takes a maximum of 4 hours for a month-long sprint.
As defined in the Scrum framework, the person responsible for presenting these results is the Product Owner who explains what has and has not been done in accordance with what was agreed during the sprint planning meeting, then one of the team members performs a demonstration of the work completed.
The team must have the courage to present what has been done with transparency and must also keep an open mind when receiving feedback.
In general,
in this meeting, in addition to receiving feedback about the work completed, they also talk about the future of the product, projections, new ideas, etc.
It is a very important space as what is said here is fed into the Product Backlog.
Retrospective
This event takes place after the review of the Sprint that has just ended and before the planning of the next sprint.
It should last around 3 hours for a one-month sprint.
It is a space for introspection for the scrum team where they review the work process that has been carried out. At this stage they identify improvements that can be applied during the next sprint.
By reviewing the development process carried out in the past cycle, the team decides what aspects of the process to improve and how to implement those improvements.
With hindsight, all the team does is execute the famous Continuous Improvement Process. At the end of the retrospective, the team has an action plan for improvements to be implemented in the next sprint.
Then, in the next retrospective, the results of the improvement plan which has been defined should be reviewed.
At this stage, a couple of things should always be kept in mind:
- "Understand that everyone involved acted as best they could, with the knowledge, skills, information and context available at the time."
- The team must "be tough on the problem and soft on the people."
At this point, the moderation of whoever is facilitating the meeting is important. Usually it will be the Scrum Master, who must have the sensitivity and skills necessary to handle conflicts which may arise during this meeting.
It is important that actions to be carried out come out of the meeting, and more importantly that these actions are then executed, so the resources required must be considered so that they can be successfully completed in the next sprint.
The 3 elements of Scrum
Retrospective
This element contains all the functionalities, requirements, correction of errors, needs and “desirables” of the product from the point of view of the user or customer.
The Product Backlog is a living element that is fed with new needs or necessary modifications throughout the lifecycle of the product, and as we have seen many of these modifications can arise from the feedback received during the product review.
Sprint Backlog
The set of elements that the Product Owner selects as candidates to be developed in the Sprint and that, together with the development team, are used to define what is required to meet the objective of the sprint.
In addition, all the tasks necessary to achieve the proposed objective must be included.
Some of the improvements to the process that emerged in the retrospective of the previous sprint should also be included.
- Can the Sprint Backlog be improved during the Sprint?
If it can be changed, what should not be changed is the sprint objective. To make it a little more clear, let’s look at the following example: it may be that during the sprint execution we realize that to fulfill that objective we need to include some task or activity that for some reason was not taken into account during planning, including this task or activity leads to us modifying the Sprint Backlog.
Product Increment
This element is the sum of the sprint backlog items completed in a sprint and that are ready to be used in production.
In a little more detail we could say that it is the sum of the Sprint Backlog items that are finished, functional, and usable to the end user if the Product Owner decides to put them into production.
An important point to keep in mind is that of when and/or how to consider an item in the sprint backlog as finished.
The “completed” criterion is something that must be agreed between scrum team members and stakeholders, and must be clearly understood by all parties.
About the Author
José Meyer is a talented Project Manager and very experienced in working with teams of diverse sizes and backgrounds. He has excellent planning and communication skills, and specializes in Agile Methodologies. José is a strong leader with a great work ethic.
