Day-to-day Scrum activities

It's day-to-day activities that contribute the most to the success of a Sprint, and of the entire Scrum, and all parties involved should do their best to keep the pace of work at its maximum throughout the project.

Text originally posted on
No pictures were retrieved after the blog was taken down.

In my previous post I wrote a little bit about the basics of Scrum – the agile development framework. I discussed the Roles and the setting up of a Sprint. However, it’s day-to-day activities that contribute the most to the success of a Sprint, and of the entire Scrum, and all parties involved should do their best to keep the pace of work at its maximum throughout the project. To do that, they need to know enough about Scrum and its methods, and it’s the Scrum Master’s job to present the Development Team with all the benefits of agile development and to provide tips and guidance for successful Sprints.

Daily Meeting

Also called the Daily Stand-up meeting or 15-minute meeting, it is the crucial part of every working day. This meeting should be attended by the Scrum Master and the Development Team, and it is strongly encouraged that the Product Owner attends it too, at least for the initial period of a Sprint. The scope of the 15-minute daily meeting is to assess and correct the progression of a Sprint. Each Team Member should answer 3 questions:

  1. What have you achieved yesterday?
  2. What will you finish today?
  3. Are there any blocks or impediments that are slowing you down or stopping your advancement?

A good additional question ishow confident are you that you will achieve what you claim? This question might bring up obstacles that were hidden or not reported because of apparent low importance, but could speed up the development if removed. Remember, the Scrum Master is not there to listen to reports – the Team should talk among themselves, while the Scrum Master should only direct the talk, keep track of impediments, suggest ways of solving them (or take on the responsibility to solve what he can) and limit the chit-chat that might occur. Those 15 minutes should be spent efficiently, so all activities and other work should stop, and all unrelated (or vaguely related) talk should be left for the 16th minute.

It is useful to remember several points that will help everyone get the most out of the Daily Meeting.

  • The Daily Meeting is the most important part of every working day in a Sprint. That’s why it’s usually done in the morning, when the ability to focus and resolve problems is at its best.
  • Starting on time and sticking to the set time frame will underline the importance of the meeting to the whole Team. If someone is late, they won’t attend, and that might have a negative impact on the Team’s work. It’s up to the developers to solve such problems among themselves.
  • Stopping all other activities and standing up (preferably around the task board) will make this Meeting more dynamic and productive.
  • In a Daily Meeting, Team Members should talk to each other. If you’re a Scrum Master, and you notice repetitiveness and dry reports, stop attending. Your mission, as a Scrum Master, is to ensure that all Team members are involved in the meeting. In every Team there is a quiet one, who would rather listen and learn, so their contribution to the Team’s work should be encouraged.
  • It’s important to let the Team make mistakes. We all learn better from our errors, than from our successes.
  • The Scrum Master should focus on trying to detect impediments, offer and discuss solutions. Sometimes the Scrum Master will remove obstacles on his own, other times he will support the Team members in doing so. The long-term goal is to enable the Development Team to overcome impediments in the shortest possible time, and hence improve their productivity.
  • Suggesting a bad solution is not a bad idea – Team members should recognise the challenge and offer a better solution to a problem.


After the initial setup of a Sprint, the main focus should be on identifying and removing impediments.

These can be divided into those that slow progress and those that completely block advancement. To deal with such obstacles more successfully, it’s important to detect them and display them for all to see. If there is a Development Team board, dedicate a corner of it to sticky notes which will represent the most urgent impediments. For easier prioritisation, limit the space/number of impediments displayed.

It is not always easy to spot impediments – Team members might not consider them to be problematic, or they might  just think they can deal with them alone. It is, therefore, crucial that the Scrum Master should actively search for impediments. There are three cases in which the Scrum Master should make an effort to find out more:

  1. If the progress of tasks is stalling for more than a day.
  2. When there are more open tasks then there are Developers.
  3. When no impediments are reported.

The last one does not necessarily mean that there is a problem – it might also mean that you found Utopia. However, in most cases, impediments of low priority will be omitted by Developers during the Daily Meeting, even though their resolution would visibly speed up the Team’s productivity.

To boost confidence of Team members, use the Daily Meeting to mention all resolved impediments. In fact, removing them from the board in front of everyone will have a good effect on both their productivity and their confidence in reporting future problems. If an unresolved impediment arises during the Meeting, put it down on the board, and use the 16th minute to discuss possible solutions.

One of the great ways to improve the quality of the code and success in finding solutions is pair coding. If a sequence of a task is turning out to be more problematic then expected, suggesting pair coding might be the way to go.

Sprint Retrospective

Even though the Sprint Retrospective is not done every day, it plays an important role in the Team’s learning and improvement. At the end of each Sprint, a Review and Retrospective can be carried out. The Review analyses the product, while the Retrospective focuses on the processes of the Sprint.

Despite the ever-present need for efficiency and speed, the Scrum Master must also create the environment for learning – only Teams which learn will thrive, and their productivity will be improved in the longer run.

classic Retrospective is intended to answer two questions related to the recent Sprint:

  • What went well?
  • What could be improved?

…but can also take into consideration:

  • What did we learn?
  • What still puzzles us?

Anything affecting the Team’s process of coding can be referred to by these questions and discussed. This includes communication, habits, tools, office environment, etc. When it comes to encouraging Team members to share their opinions and ideas, similar tips apply as for the Daily Meeting. However, the Retrospective meeting allows more time, and some might want to use it to detect communication problems within the team. Checking the level of safety that Team members feel (anonymously), with or without management present (i.e. the Product Owner or Scrum Master) can be easily done by asking the Developers to write down whether they think their ideas would be accepted, discussed, rejected or not heard at all, if presented on a meeting. Try to alleviate the consequences of the unease that the Team members are feeling, by dividing the Team into smaller groups or hiring an external facilitator.

Another way of doing the Retrospective is the Timeline Retrospective. By placing sticky notes on a visual timeline, Team members can easily spot the key moments in the Sprint, where a misunderstanding, discussion or disagreement occurred. These are the moments they should be focusing on, to make sure that everyone learned something and the right decision was made.


And, at the end, don’t forget to say “Thank you“. You wouldn’t believe how much these two words can change the mood and relationships within a team.