What is a Daily Scrum, what questions do the participants answer and how does it work in practice?
Daily Scrum Definition
The Daily Scrum is a daily meeting where the development team meets to share progress, upcoming activities, and potential problems with each other. It is a central component or event in Scrum. Since the participants stand up in a circle for dialogue, it is also called a stand-up meeting or daily stand-up.
Participation in the meeting is mandatory for the development team, in addition the Scrum Master and the Product Owner should participate. Representatives from other areas such as marketing, sales or documentation can also take part in the meeting. However, guests do not have the right to speak. The time, duration and location of the Daily Scrum are fixed and do not have to be agreed from meeting to meeting.
The Daily Scrum is NOT a status meeting
The team members report on their open and completed tasks; thus they provide information about the status of the development. However, this information is intended for other team members, not supervisors, not the Scrum Master or the Product Owner. It is an exchange among peers, all other participants are just listeners. It’s about synchronisation and not accountability.
Two aspects are essential in the exchange with each other:
- Responsibility is not given in the Daily Scrum
- and it’s not judged over others.
If required, necessary adjustments are agreed upon together to ensure that the sprint goal is reached. For this reason, the Daily is also referred to as a Collaborative Planning Session.
The three questions in the Daily Scrum
At the Daily Scrum each team member has to answer three questions:
- What have I been doing since yesterday to help the development team achieve the sprint goal?
- What do I do until tomorrow to help the development team achieve the sprint goal?
- What is preventing me or the development team from reaching the sprint goal?
When answering the questions, it is important to have an individual orientation towards the sprint goal, which has been defined by the team and which must be achieved together. “With regard to the sprint goal, since yesterday I have…” – would be a useful sentence structure that puts the focus of the answer on the achievement of the goal. Command-and-Control gives way to self-organisation and team responsibility.
The Daily Scrum in practice
The frequency at the Daily Scrum
The Daily Scrum takes place every day, as the name implies. Depending on the industry and experience, there may be considerations to change this frequency and give the team more effective working time, e.g. by holding the stand-up meeting only every 2nd day. For a 9-member team, this would be a saving of 4.5 hours in a 2-day week without the daily and 6.5 hours the following week. However, this also reduces the contact points of the team from 100% to 60% or 40%. And what happens if information that has not been communicated leads a developer to develop an entire working day unnoticed in the wrong direction, just because there has been no coordination with his colleagues? There is information that must not be communicated with a 24-hour delay. Adjusting the frequency can therefore be risky.
Timeboxing at the Daily Scrum
Communication is very important in Scrum. In order for this communication to take place in an orderly fashion, there are various events such as the Daily Scrum. Many events mean a lot of time and effort – the timebox concept helps here. The Scrum Guide recommends limiting the Daily Scrum to 15 minutes. Of course teams can also agree on 20, 25 or 30 minutes, but an extension is multiplied by the number of participants. If a team decides for 25 instead of 15 minutes, this means with 8 participants 400 minutes additional expenditure per week alone for the tuning among themselves. In almost seven hours one or the other user story can probably be realized.
In order to keep the agreed timebox, it is necessary to communicate sensibly with each other. For example, it makes little sense to discuss a problem in front of the entire group if two team members can simply solve it in private.
Taskboard in the Daily Scrum
A central element when working with Scrum is the visualisation of the tasks in the form of a taskboard. The different tasks to implement a user story move from To Do to Work in Progress and To Verify to Done. If there are impediments to a single task, this can easily be visualised with dots.
Through the shared presentation of tasks and progress in the Daily Scrum, each team member knows what needs to be done to achieve the agreed sprint goal. Transparency and awareness of the status quo are increased.
In addition to the permanent visualisation of the tasks in the developer’s office, the manual shifting of tasks promotes the motivation of the employees to achieve the set goals. When electronic taskboards are used, the effect is less pronounced. Updating the burn-down chart does not have this effect either.
Impediments in Daily Scrum
What prevents me or the development team from achieving the sprint goal? The answer to the third question in the Daily Scrum is an impediment. An impediment is a disorder. It impedes team members in the performance of their tasks, delays individual or joint development, and consequently endangers the sprint goal.
When dealing with impediments, the Scrum Master is required either to encourage the team to remove the obstacle itself, if necessary, or to take care of the removal of the cause. Ideally, the Scrum Master should report on the progress of the impediment removal at the next Daily Scrum.
What to do in case of delays?
Not all participants are always present on time at the beginning of the stand-up meeting. Opinions differ on how to act in such situations. In some organisations there is the instrument of punishment. Even the smallest amounts of money or the investment of time – e.g. for baking a cake at three delays – quickly lead to a change in behaviour.
In principle, however, it is more important to understand the background to delays. A developer who is held up by a manager may not be able to “free himself” and leave. The Scrum Master should therefore try to find out the reasons for the late arrival and then work on it together with the team or the affected team members. In most cases, this leads to lasting improvements and does not just fight the symptoms like a punishment.
Even if it is against the mutual agreement to repeat discussed content for people who arrive too late, teams must still find a solution how to communicate any information “afterwards”. Usually it is sufficient if one team member – not the Scrum Master or the Product Owner – takes over this task after the Daily Scrum.
Challenges for companies
Consistent orientation towards the sprint goal
The Daily Scrum is about the planning of the day by the development team. It’s about completed and open tasks, it’s about obstacles and it’s about collaboration in the sprint. Ideally, the product owner is present and able to provide information. The Scrum Master ensures an effective process and takes care of the removal of impediments. By exchanging information, the team synchronises itself and redundancies are avoided.
It is important that the Daily Scrum does not degenerate into a compulsory event within the framework of Scrum because there is no serious exchange between the participants. If individual employees think that they could do more meaningful things during the meeting and, for example, implement individual user stories, the Daily Scrum is anything but ideal. This is where the Scrum Master is required and where orientation towards common sprint goals helps. Agile software development doesn’t mean that every single developer does his job, it means that the whole team is responsible. Every developer should be aware of this responsibility and understand the Daily Scrum as the basis for a successful cooperation. Consistent orientation towards the sprint goal helps here.
We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and consider stakeholders, goals and boundary conditions. And we plan and control your projects with these requirements on the basis of defined processes.