Daily Meeting? Standup Meeting? Daily Standup? These are typical names that we find when talking about the Daily Scrum. What if I tell you that none of them is correct?

Although the Daily Scrum is the simplest Scrum event, it is where we make the most mistakes. And if we are wrong when naming this meeting, how can web e sure we are not mistaken when doing it? Let's make the Daily Scrum productive! But how?

What is the real goal of the Daily Scrum?

We must be clear that the Daily Scrum is a Scrum event that is performed daily during the Sprint run. Its main mission is to serve as a thread between the members of the Development Team to reach their Sprint Goal.

Remember that the Sprint begins with a Sprint Planning where we get a Sprint Goal that the Development Team will try to undertake.

Let's look at some of the myths that revolve around the Daily Scrum and how we can correct these bad practices.

Myth 1: It should be done first thing in the morning.

The best time of day to do the Daily Scrum will be determined by the Development Team. The set time must be kept constant, as well as the place where it is going to be done, thus we will avoid wasting time each day deciding where to carry it out.

Another premise is that the event will be held daily, something that seems obvious as its called "Daily", but in many teams this is not met.

Myth 2: You have to stand up.

Another myth is that the Daily Scrum has to be done standing up. This is a technique that is applied to avoid lengthening it for more than 15 minutes, the maximum recommended time.

To do this, each Development Team has to self-organize and it is the Scrum Master who must teach them and help them achieve it. A good sign of this is that the day the Scrum Master is absent, the event develops successfully and works.

Myth 3: The duration depends on the number of people involved.

Remember that the maximum time the Daily Scrum lasts is 15 minutes and will depend neither on the number of participants nor on the size of the Sprint.

Myth 4: Each assistant has to speak for a maximum of 2 minutes.

Another widespread misconception is that every person who goes to the Daily must have 2-3 minutes to intervene. This technique is valid but is nevertheless not the best since it is possible that some people need more time and the team considers that not everyone should speak for the same length.

One of the best options is to have a stopwatch. Thus, each participant is aware of the time he has used to speak.

Myth 5: The Scrum Master and the Product Owner must attend.

The people who must attend the Daily Scrum are only members of the Development Team. They are responsible for getting it right. The Scrum Master, the Product Owner, or any Stakeholder may attend as listeners, but are not required to do only as long as it is useful to the Development Team.

Although Product Owner assistance is not mandatory, it doesn’t matter if they are there as a listener because it can facilitate the resolution of any impediments. Of course, it is important that the Product Owner doesn’t end up using the event as a way of controlling the Development Team.

Myth 6: Objective: to tell what was done the previous day, what is done today and if there is any impediment that does not allow us to carry out the tasks.

The Daily Scrum has in many cases become a report meeting where each participant assists with the idea of ​​proving that they are working. However, the goal of the Daily Scrum is to know whether or not we will reach the Sprint Goal.

If we are not going to reach it we will have to talk to our Product Owner to renegotiate the items and that the Goal is viable. That's why the Daily Scrum's job is not to answer questions about what we did and what we are going to do, but rather to analyze the status of our Sprint Goal.

Myth 7: The Sprint Burndown is updated with the hours that were spent on the previous day.

The Daily Scrum is an Inspection and Adaptation opportunity of our Sprint Backlog, during which we inspect the progress made during the last 24 hours and update our Sprint Backlog in order to reach the Sprint Goal. All unforeseen work that has emerged must be contained in the Sprint Backlog. Without transparency we will not know what we are inspecting!

Other techniques to improve our Daily Scrum

There are more techniques that we can teach our Development Team:

• For example, if you have problems listening, you can use a throwing ball to prevent people from disconnecting as they can be touched at any time.
• If the problem is that team members are very disrupted, you can use a totem object that indicates who can speak.
• To solve problems of length, you can use a stopwatch that we will place in a visible place so that the Development Team is aware of the time available.

One technique that a colleague of ours invented is the "surprise exam". As we seek a shared understanding of the status of our Sprint Goal, we can pass a post-it to each member of the team at the end of the event.

In this post-it each participant points the percentage of Sprint Goal achieved and if they believe that they will be able to fulfill it at the end of the Sprint. Then they are all put in common and you can see if the perceptions of the team are aligned or not.

If we want Scrum to work, it is essential that we read the Scrum guide, receive training from qualified people and do not stop training and learning. If every Scrum event is adulterated we will begin to believe that Scrum does not work when the real problem is that we are not applying it correctly.

Let's learn how to improve! That is the best advice we can give.