Daily Scrum - Lessons Learned from a PM’s Perspective

About Daily Scrum In Theory

Daily Scrum, sometimes called daily stand up, is a 15-minute time-boxed event for the Development Team according to the Scrum Guide. The Daily Scrum is held every day of the Sprint. During that time, the Development Team plans to work for the next 24 hours. The goal of the Daily Scrum is to inspect progress towards sprint goals and adapt actions/plans if needed. There is no one proper way to conduct this event, and the team can define it. The Scrum Guide gives examples of the questions that can be used to help to achieve the goal of this event:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Our teams use this event in most of the projects even if these are not conducted in Scrum by the book. While working on the project with a fixed timeline & budget, but not a fully defined/fixed scope, we would usually proceed with development in two-week Sprints, and use the majority of the events defined by the Scrum Guide including Daily. What does not go by the definition of the Scrum Guide are 2 roles: Scrum Master and Product Owner (PO). In addition to the Development Team (about 8-9 people max, usually less), the project team also includes the Project Manager (combination of Scrum master and POs responsibilities) and Business Analyst (Majority of POs responsibilities).

Can Daily Scrum be used and work well in such an arrangement?

I think yes, but only if you are really using it right.

These are a few of my lessons learned from the past 5 years. Some of them came out naturally over time together with the team we were implementing into different improvements. There were also “fixes” added after getting more in-depth Scrum knowledge.

Make sure everyone understands the goal of the Daily Scrum

Although it seems obvious, reality shows something else. Do not operate on the assumption that everyone in the team understands the idea of this event. New people joining the company and new team members who previously worked on other projects will have a different methodology/framework. They all come to a new project with different knowledge, habits, understanding (or not understanding) of Scrum events and roles.

During project work several times I encountered situations where team members were giving their updates and didn’t mention that they had already exceeded the original estimate of the task. They kept working on it till the end of the day and only then reported to the PM that they will not be able to complete it without the support of someone else from the team.

Another example would be when team member started to work on a user story, realized there are some impediments, and instead of communicating that during the Daily Scrum, they switched to a different user story.

With the last case, I would like to mention that there are team members ensuring they are on track with their assignments and letting the team know on the penultimate day of the sprint that they will not be able to make it, and therefore would need support.

Educate the team and make sure everyone uses the same language and has the same understanding of the Daily Scrum. Remark its core purpose which is inspection and adaptation towards sprint goal. Practical tips for this education would be to present this explanation in a kick off presentation, including real-life examples of misunderstandings. Remind it shortly before the first few sessions of the Daily Scrum. If you still notice some shortcomings, make sure they will be raised during the retrospective.

Do not use Daily Scrum as status meeting for the whole project

If this were happening, it would have been caused mostly by PM’s/BA’s. Having a very broad context of the project (overall timeline, budget, resources, third-party services, whole communication with the client), and daily meetings that are already scheduled, sometimes it is really tempting to share the latest updates with the whole team, although they are not related to the goal of the sprint. My experience shows that even though the updates seemed super brief, it was followed up by many questions, and at the end led to distractions and the meeting taking much more time than expected. Less often is the case that team members were giving updates on company-wide events/matters, their vacation schedule (the ones not affecting the current sprint), or were trying to clarify something they heard about the project over coffee. Online sources describe interesting ideas on how to remind team members that something shouldn’t be part of the Daily Scrum For example:

Picking up a rubber rat to indicate we’re going down a rathole, throwing plastic at someone, having a keyword that can be used by all participants in case someone starts to drift in an undesired direction, etc. In my experience, an indication that this probably can be discussed after the Daily Scrum was enough. Usually, we would spend another 10-15 minutes on further chats to answer some questions and ideally remove impediments.

If outsiders join the Daily Scrum, make sure they know the rules

Sometimes, other managers, directors or CEOs decide to join the Daily Scrum, so they can say, “check how the things are going”:). It does not seem like an issue as long as “guests” do not interrupt the team’s routine. It happened they were trying to start a session of problem-solving during the meeting or sharing some client’s related update (same as described above). In cases where I was informed upfront that someone will be joining the Daily Scrum, I would try to clarify the rules right away. If that was an unexpected visit and caused delays, instant feedback right after the Daily Scrum was usually enough to avoid the same issue in the future. Make sure you actually take action instead of just complaining about it.

Visualize so everyone knows what we are talking about

When working with bigger teams (9 people) and on the user stories with many dependencies, it is really easy to lose track of what someone’s update during the Daily Scrum is about. What we found helpful was displaying a sprint board on the screen in the middle of the room. It would depend on the sprint backlog, but sometimes it was more clear if the update was made a story by story, not person by person, as several people were working on one story. Sometimes we also used a whiteboard with a short summary of the stories/features we were working on and marked if something was done or blocked during Daily Scrum.

Make sure team members actually answer 3 questions

As mentioned above, the Scrum Guide gives examples of the questions. Of course, these are only suggestions, but we usually use them to facilitate the meeting.

The issue we noticed was that people keep talking about the things they were or will be working on, but didn’t specify if/what was actually completed, or how far from completion they are. “Inspect progress toward the goal” part was actually missed.

My solution for this area is to do a quick follow up and ask about the completed/accomplished part. Usually, after several times, team members remember to be more specific and give an update on the progress.

I hope you find some of my lessons useful! In case of any questions, drop me a line.

Read also

Most Read

1 What is a legacy system, and why do companies keep using them?
2 Mobile payments security. What should developers know about it?
3 How to fold QA into every sprint
4 Software development view of healthcare wearables
5 How to quickly add a date dimension to a Pentaho Mondrian OLAP cube
6 Nearby Messages: Sharing Information With The Person That Is Near You
7 Creating a digital product for the healthcare industry?
8 7 reasons to use real time data streaming and Flink for your IoT project
9 How to create an effective Asset Tracking System?
10 Minimum Viable Product (MVP) in software development - what it is and how to define it. Product Owner and Project Manager perspective.

Digital products from concept to launch

We understand that creating a product is a challenging and risky endeavor and believe that having a partner with experience and know-how is a critical first step.

Learn More

The Digital Product Journey

From idea to launch we guide you through the startup experience

Learn More
Path Created with Sketch.

Before you head out, you can download our latest E-book “18 Software Product Killers Every HealthTech Strategist Needs to Know (part 1)”

Yes, we know it's a mouthful, we're working on it. Enjoy!