Daily Scrum Meetings : 11 Best Practices

Daily Scrum meetings are everyday meetings for the entire project team. To make these meeting more effective the following best practices will be useful. Scrum meetings are crucial to ensure the entire team is on the same page.

Scrum Meetings Best Practices
Scrum Meetings Best Practices

Rule 1: Fixed Talking Points

Every team member attending the scrum meetings should answer the below questions -

1. What did I do yesterday.
2. What I will be doing today.
3. What are my impediments.

The first question and the second question are about the the project related tasks that were done yesterday and what will be done today. This gives everyone an idea about what that team is working on.

Impediments are nothing but road blocks or issues that a particular team member is facing. Examples of impediments are " Server access not setup", " unplanned environment outages",  " functionality not working" etc.

Rule 2: Scrum Master In Control

  • It is important that the scrum master is in control of the meeting through out the time.
  • If anybody deviates from the above talking points then the scrum master should bring the discussion back on track.

Rule 3: Same time and same place everyday

  • It is important that meeting is conducted at the same place and time everyday.
  • The meeting has to be done on a daily basis to be effective.
  • Ensure that you send out a recurring meeting invite with the talking points, time and place.
  • The first few times people will come a bit late or will be disorganized but once the meeting is running for a couple of weeks people will turn up without reminders.
  • Also choose a wall or board which is visible to other in the office or floor so that they know things are really moving.

Rule 4: Always stick to 15 Minutes Meeting

  • The daily scrum meeting should be wrapped up in 15 mins max everyday.
  • Any detailed discussions should be take  on the side. It is important that the scrum master enforces these rules so that people don't waste others time.

Rule 5: Meeting Rules Notice

  • It is a good idea to have all the basic rules displayed near the meeting area.
  • It  can be a simple print out with the rules listed as simple bullet points.

Rule 6: Full Team must attend

  • It is important that all the people from the project team attend.
  • Generally, it takes a day or two for people to get used to the meeting so be patient.
  • If someone is not attending then it is good to remind them by calling them or giving them a tap on the shoulder by going to their desk.
  • If the someone is missing the stand-up regularly then it is better to escalate the issue.
  • Full team includes the product owner.

Rule 7: Only One Conversation or No side conversations

  • From time to time there will be people with the nasty habit of starting side conversations during stand-ups.
  • The scrum needs to remind everyone from time to time that only one conversion needs to happen at a time

Rule 8: Always move cards /statues during the meeting

  • Team members should move cards or update statues only during the meeting so everyone is aware.
  • This will also ensure the scrum master is aware of what task is actually progressing.
  • If a scrum master sees that team member does not move the statues for a few days then he or she can check with the team member to to see if everything is alright.  

Rule 9: Review the backlog everyday

  • The scrum master should review the backlog every single day with the team.
  • It is also a good practice to make any updates in the front on the backlog so that the team is aware of changes to the backlog.

Rule 10: Done is actually done

  • A scrum master must define what does completing task include. 
  • Depending on the type of task the documentation and process that needs to be followed will vary.
  • For example if we are talking about a Test Case execution then the team member should ensure that with the actual execution of the test even the documentation and relevant sign off are completed. 

  • Similarly for a UI Design it is important that with actual design completion the documentation, review and sign offs are complete as well.
  • So it is important that the scrum master ensures all the required checks are complete before the item is marked as complete.

Rule 11 : Leaving items / cards in the done column

  • This is a major moral booster for the team. When you move items to done column it is a good idea to leave them there for at least a few days.
  • Everyone gets a sense of achievements when they see many done items on the scrum board.
  • You can leave the items as long as you can but necessary to leave it there forever.
  • Many time people who pass by also notice the progress and always keen on items in the done column. It gives a clear picture to everyone what the project team has achieved.

The Sprint Planning Meeting

  • In the Scrum framework, each incremental iteration of a project is developed during a short work period, typically one or two weeks in length, called a Sprint. 
  • Each Sprint consists of a consistent series of meetings. 
  • The first meeting of each Sprint is the Sprint Planning Meeting.
  •  During the Sprint Planning Meeting, the Product Owner communicates to the team a list of priorities for the project, known as the product backlog.
  •  The Team decides which items from the backlog can be completed during the Sprint, and the Team and Product Owner, in collaboration, set priorities for the Sprint. 
  • The resulting list of goals is known as the spring backlog.
  •  The Team builds a set of tasks that will allow it to complete the priorities during the Sprint.

The Daily Standup Meeting

  • Each day during the Sprint, the Team meets to review progress made the previous day, to present a plan for the day ahead, and to express any concerns about challenges that Team members have encountered. 
  • These meetings are typically short, and the focus is on preventing time lost due to irrelevant discussions.
  •  When Team members identify obstacles they've encountered, the Scrum Master develops a plan for removing those obstacles.
  •  When Team members have concerns that require more discussion than the concise Daily Standup allows, they may meet separately in a sidebar meeting following the Daily Standup.
  •  Each day, goals reached or not reached are recorded on a burndown chart, a graphic representation of progress made to date on the project.

The Sprint Review Meeting

  • At the conclusion of each Sprint, the Team and the Product Owner come together in a Sprint Review Meeting to review the work done during the Sprint and assess whether or not the Sprint's goals were met.
  • At each Sprint Review Meeting, the Team demonstrates a functional, potentially deployable product to the Product Owner and other client stakeholders.
  • Through his or her review of the product, the Product Owner determines if the Sprint's priorities from the sprint backlog have been completed or not.

     The Sprint Retrospective Meeting

  • Following the Sprint Review Meeting, the Team and the Scrum Master meet without the Product Owner present to review the successes and challenges the Team encountered during the Sprint.
  •  Team members are encouraged to speak honestly during the Sprint Review, expressing their concerns about things that went wrong during the Sprint and giving suggestions for improvements.
  •  After concerns are expressed, the Team compiles a short list of process improvements to be employed during the next Sprint.
  • In large-scale projects with multiple teams working independently from one another, an Overall Sprint Retrospective with a clear agenda Meeting may be convened to review interactions between the teams, as well as interaction between the teams and the rest of the organization. 
  • Check out Sprint Retrospective Meeting Agenda Template.

Onward to the Next Sprint

  • After the completion of the Retrospective Meetings, the process begins again. 
  • The Product Owner and Team come together for another Sprint Planning Meeting, during which new priorities are drawn from the product backlog and goals are set for the next Sprint.
  • The process continues, with each Sprint resulting in a new iteration of the product, until all of the priorities of the product backlog have been achieved and the product is complete.

No comments