Is it true that in Scrum there are too many meetings? Events in Scrum

I often hear from some Scrum teams that the framework has too many meetings.

In Scrum we talk about events, rather than meetings, to differentiate these team meetings from what we traditionally know as meetings.

The official Scrum Guide states that the purpose of Scrum events is to creating regularity and minimizing the need for meetings not defined in Scrum. All events are time-boxes with a maximum duration, and with the exception of the Sprint which has a fixed duration, the other events can end as long as their objective is achieved, ensuring that an appropriate amount of time is spent. without allowing waste in the process.

The events in Scrum are:

  • The
    Sprint
    is the heart of Scrum, a block of time (time-box) between 1 and 4 weeks, during which you create a increase in product “Finished”, usable and potentially drop-down. The sprint contains the rest of the events.
  • The Sprint Planning or sprint planning, where the Scrum team aligns priorities and agrees on sprint objectives and goals. The Sprint Backlog with the functionalities to be incorporated into the product and at least 1 improvement action agreed in the retrospective. It can be done in 2 parts: What is going to be done in the Sprint, led by the PO, and How the technical team will approach the development.
  • The Daily o daily meeting, where the technical team synchronizes the work and establishes the plan for the following 24 hours. Each developer communicates what he/she did, what he/she will do and what prevents him/her from meeting the sprint objectives. It is not a status meeting. Here, teamwork is promoted and the SD takes away the impediments to manage their solution.
  • The
    Sprint Review
    or sprint review meeting, to inspect the Product Increment developed during the Sprint and adapt the Product Backlog if necessary. The Scrum Team and stakeholders collaborate to determine the next things that could be done to optimize value by reviewing and adapting priorities for the next Sprint.
  • The
    Retrospective
    or Retro, where the team inspects itself, reflecting on how it has performed its work in the last Sprint and creating a plan for improvements to be addressed in the next Sprint.
  • The Sprint Refinement o Refinement of the Backlog elements, to increase the level of concreteness of the stories that, due to their priority, are approaching the next sprint. It includes the incorporation of new stories, division of the larger ones, rethinking, detailing and estimation of already defined stories. Allows the Dev Team to better understand the product.

The following figure shows when each event is performed within the Scrum cycle and the approximate duration of these events, according to my experience, with sprint of 2 weeks and teams with a certain maturity that have between 3 and 7 developers.

There is no alternative text for this image

Scrum events are designed to enable the vital pillars of
transparency, inspection and
y
adaptation
as well as to promote the communication and collaboration among team members.

It also facilitates the implementation of a development model iterative and incremental, where the Scrum team incorporates the PO and key business and systems stakeholders, with the objective of focusing the teams on delivering value, empowering team development autonomous, self-managed and multidisciplinary, elements that promote the motivation and efficiency of the equipment.

It is normal, when having the team together in Scrum events, to be tempted to “take advantage” and want to solve other issues. In addition, we are social beings, some people are more conversational in nature than others, and generally, We don’t like to say No, interrupt or set limits.

This, together with other difficulties, causes the sessions to drag on and sometimes even become unproductive, generating doubts in some team members about the usefulness of these events for the team.

For this reason, the following questions arise questions on the realization of each event:

Sprint Planning: And if we do not plan, can the team articulate the development of product increments, and maintain frequent and periodic deliveries of value, with efficiency and technical quality, without going through a joint planning and estimation process?

2. Daily: Eliminating these 15 minutes a day, can you avoid other meetings for synchronization, alignment, collaboration and communication among team members?

Sprint Review: How to get feedback from the business and how the product should evolve, without this event? Can you think of another way to do it?

4. Retrospectives: Do we take away this meeting where the team has the opportunity to meet, resolve their differences and improve their processes and interactions?

5. Refinements: And if we do not refine in a separate event, we still need to refine using the time of other events. Is it better to extend the time of other events and reduce the number of events? How about the focus and purpose of each event?

I would very much like to receive your reflections on these questions, and thereby broaden and complement perspectives on this issue.

In any case, what should be the challenge and goal of every Scrum team is to to achieve productive Scrum events that achieve their purpose and eliminate the waste that usually occurs.

María Esther Remedios

@soy.agile.coach

Recent articles

Imagen principal de la noticia de tipos de Ingeniería Social

Types of Social Engineering

Phishing: It is characterized by searching for personal information, names, addresses and security numbers. It uses links that redirect to suspicious sites, with URLs that…

Social Engineering

Social engineering is a set of techniques used by cybercriminals to trick unsuspecting users into sending them sensitive data, infecting their computers with malware or…