Home / Blog / Agile Outsourcing

Guide for Truly Effective Daily Scrum

In today’s world the remote work environment is the norm, the law, “the new normal” as they say. However, there are some specific challenges to overcome that may not have been anticipated when the original Agile and Scrum revolution began.


Those really curious among you may ask – what challenges?


Communication between teammates is significantly more difficult because you are not “there” and must use your keyboard, for example, to carefully ask a question rather than telling it to your teammate on your way to the copy machine. It is far more difficult to keep track of colleagues’ progress, if someone requires assistance, and so on.


It all boils down to a contemporary problem of not being able to see and truly connect with your fellow teammate.


The solution to this conundrum is to connect daily, where we speak openly about our and team’s whereabouts, we scrutinize everyone’s pain points and we agree on actions that will genuinely re-instantiate sprint order.


Here is a list of steps for doing daily scrums the right way!   



How to Do Daily Scrums With Your Team?

Step 1: Decide the Single Driving Question for Your Daily Scrums


It is critical for you to determine the driving question before you put your daily scrums in the calendar and begin. Otherwise, simply asking the three prescribed questions might easily lead your meeting astray.


People get used to those three questions and it becomes a routine for them to answer them from sprint to sprint. This way, the team slowly but surely loses its sharpness and standups are much like bad stand-ups (except here, everyone are comedians and the only thing that is missing are jokes)


Every Scrum master must counteract this tendency by firmly leading every daily scrum with the right question, the question aimed at fixing the most significant identified problem in your retrospective.


Daily scrums shouldn’t be random discussions about trivial matters or random talks without a clear goal. Instead, there should be a single driving question that reinforces the current goal for the team. 


The driving question within your daily scrums may change over time depending on what is the problem you wanna work on as a team in any given sprint. 


Since most teams are struggling with bugs and poor code quality (let’s be honest, I am struggling with this article right now), we will assume your driving question will be quality-driven (are you enjoying this article?). 


This is a great way to constantly remind your team what is the biggest pain point and how we are trying to improve it every day.


Here are examples of good driving questions for daily scrums:


1. Was there any returned ticket yesterday from code review that did not fulfill DoD? 


2. Is there a ticket returned from QA for not passing basic acc criteria (e.g. it was deployed while even the happy flow was broken)?


3. Is there any impediment raised but still not solved that will prevent us from reaching our sprint goal?



Step 2: Schedule Regular Timeboxes for Your Daily Scrums


Some teams mistakenly think that it is ok to prolong or reschedule daily scrum “as needed” in an ad-hoc manner. Oh boy, are they wrong.. No, seriously, this is always a bad idea.


Not only are they damaging transparency and removing the opportunity for the team to inspect/adapt but they are also preventing themselves to keep the big picture, keep their eyes on the true sprint goal (delivering the stuff will not make you successful as a team, let alone deliver a valuable sprint goal set together with the PO).


You should schedule a regular timeboxed daily scrum and stick to it every day at the same time. This will help you in organizing other activities around it and ensure sharpness and consistency.


Think of creative ways to have a highly valuable meeting for everyone while sticking to those 15-minute timeboxes. Insert couple of jokes in the beginning like: Why did the chicken cross the road? Because it was her sprint goal.


Be always at an agreed time at an agreed place. Be a Gandalf the Gray Scrum master by never being late or early, but by coming exactly on time.


Do not succumb to time pressure, stay loyal to your quality standards. Having 1 feature done properly is way more important than having done 3 but skipping important steps in the process.


Step 3: The Outcome of a Daily Scrum Meeting Should Be a “Daily Plan”


The output of daily scrum is a daily plan. Make sure that the daily plan is out there, visible to your teammates. You need to put it somewhere where others can see it and extract needed data later. 


To do this, the most rudimentary option is to put a daily plan in the form of a bulleted message in a team chat. But eventually what you really want is a more data-driven approach (more on that below).


Re-iterate and wrap up an agreed daily plan and actions for the day, in the last minute of daily scrum. That will be your structured input for the next step.


Daily plan


Step 4: Log Each Daily Plan and Impediments


Consider daily scrum meetings to be the antithesis of illegal activity. You must leave as many traces as possible.


This may be done via chat, excel, Google sheet, or the Jira app. During a daily scrum, you must incorporate the meeting’s output into a daily plan. To keep things simple, the daily plan should just include two fields: “sprint health” and “notes”.


Here are examples of preset values for sprint health: 


On Track: We are all on track to hit our individual set target dates per feature/ticket/bug so we will hit the sprint goal together as planned.


Impediment – Unknown: At least 1 teammate skipped today’s daily scrum and no one could fill us in on his work, so there is a risk that something is going wrong but has not reached us yet.


Impediment – Wrong Scope: We’re working on things that aren’t priority or relevant to the sprint goal.


Impediment – Behind Schedule: This is similar to the one above, meaning that we will not deliver entire backlog, so priorities are to be readjusted (variant of Wrong Scope).


Impediment – Wrong Process: We are miscommunicating or missing each other expectations (or someone’s else expectations) due to not following team or other agreements (or we don’t have agreements and we need to set them).


Impediment – No Backlog: At least 1 teammate is underutilized because there is no work he/she can pull and work on.


Blocker Impediment – Needs Action: At least 1 teammate is stuck and needs action or decision from another team or person.


Blocker Impediment – Too Hard: At least 1 teammate can’t think of a way to proceed, or has tried ways to proceed, but they haven’t produced results or found a way forward yet.


Notes section is to be used below each status to put agreed actions or any other useful notes that will help the team come out of any impediment and move into “On Track” status on tomorrow’s daily scrum.




Step 5: Use the Data to Retrospect on Sprint


This is the most important step that most teams skip. Now that you are doing daily scrums on a regular basis in the way mentioned above, you must ask yourself: what can we learn from the previous sprint in terms of how the work’s been done?


As a Scrum Master, you can pose this question during the sprint, but you must ask it at the very least during the retro.


You should list out the top 3 failures (for example, is it us not being transparent, not inspecting on time, not identifying proper adaptation). Then, you should list the top 3 actions you are going to take to increase quality (process or product) in the next sprint. 


Keep in mind that when new Scrum Masters begin actively participating in daily scrums with their teams, they believe that the majority of the action items will be allocated inside their team. Which is.. Wrong!


While there is work to be done within the team, the majority of the time there are outside obstructions impeding the team. As a result, following a daily scrum, SM should generally have the most action items.


Now that we’ve learned how to use data effectively, let’s look at an example of daily scrum logs and what we can learn from them. 


Daily Scrum Logs and Extracted Learnings Example


Scrum Team – Challengers:


1. In the past sprint we did 10/10 Daily scrums, out of which only the first 2 were “On Track”.


2. The driving question during the sprint was: “How many PRs passed PR DoD yesterday (first-time-right)?”


3. Our top 3 insights and actions are:


Action 1: Introduce local dev test to verify acc criteria as part of our PR DoD. This will increase the quality by 20% (based on learning from ticket JLR-3).


Insight: The team has too mild DoD which is why passing DoD does not guarantee quality. While the calculated quality according to PR DoD is 97%, true quality level is closer to 65% (based on the number of tickets that required revision in the last 4 sprints).


Action 2: Change our Definition of Ready to include integration points and their data model as mandatory part of each user story. This will prevent misinterpretations/assumptions and will increase accuracy of delivery (based on learning from ticket JLR-4).

Insight: Acc criteria are abstract and rely on previous/past knowledge of the platform. This leads to unnecessary rework and confusion in the team, resulting in wasted time that might have been utilized to produce value elsewhere.


Action 3: Introduce static code analysis tool. 1/5 features were rejected by Platform team due to not adhering to coding standards set by the company (based on learning from ticket JLR-2).

Insight: Company has strict policies around unused code, exception handling and variable scoping and naming. While these are being checked as part of PR DoD, they are cumbersome and slow checks, which could be automated and improved through a static code checking tool. 


The Bottom Line


Let us summarize and distill this article. It’s the question, Neo. It’s the single question that drives scrum meetings. Daily scrums should be organized in one regular slot every day, with the output being a daily plan.


It is critical to conduct daily scrums and log impediments and action points. Finally, using that data during retro is a key learning opportunity which will help you in planning more effective and productive sprints in the future.


Goodbye and best of luck!


If you have an ongoing software development project or want to start one, we offer free consultations.

Let’s talk