Daily Scrum Meetings & Best Practices

Scrum meetings are crucial for the success of agile teams. Below is a summary of the various meetings that are necessary for a scrum team to achieve its goals.

“Let everyone try and find that as a result of daily prayer he adds something new to his life, something with which nothing can be compared.” — Mahatma Gandhi

Daily Scrum: This is a daily meeting attended by all members of the scrum team. It should last 15 minutes or less and take place at the same time and place every day. The scrum team discusses how progress is trending towards the sprint goal, but more importantly, this is a time for the team to come together and support one another. During the Daily Scrum, the team should address three points:

• What did I do yesterday to help the Development Team meet the Sprint Goal?
• What will I do today (in the next 24 hours) to help the Development Team meet the Sprint Goal?
• What impediments are preventing me or the Development Team from meeting the Sprint Goal?

Best Practices:

• This meeting is for the scrum team only. Managers and consulting members should not interfere.
• This is a stand-up meeting that everyone must attend, regardless of their role or designation.
• This is a quick decision-making meeting, not for prolonged discussions. If more time is needed for a decision, a separate meeting should be scheduled.
• If a team member is late, the meeting should proceed without them.
• The meeting should take place at the same location every day, ideally where the team sits.
• The Daily Scrum is most effective when held at the start of the day.

“An ounce of performance is worth pounds of promises.” — Mae West

Sprint Review: The Sprint Review takes place at the end of the sprint and involves the scrum team, Product Owner, and any other stakeholders invited by the Product Owner. The main objective of this meeting is to receive feedback on the product increment that was delivered as agreed upon in the sprint planning meeting. This allows for course correction in case of changes in market conditions and the product backlog for the future.

Best Practices:

• The Development team is responsible for the “Demo” and should showcase what was done so far, answer questions, and take feedback for improvements.
• The Product Owner should discuss the current product backlog and propose any revisions to delivery dates based on the progress made in the current increment.
• The Development team should highlight any issues, impediments, and technical challenges they faced and how they resolved them.
• This is not a status meeting, and the entire group should collaborate on what to do next.
• For a one-month sprint, four hours is ideal, while two hours are sufficient for a 2–3 week sprint.

“In sport, there is always room for improvement. Whenever I see my innings against the West Indies or Australia, I think, ‘Maybe, I could have done this better or should have changed that.’ See, cricket is a skill game, and one can always improve upon the impact one has on an innings.” — Yuvaraj Singh (Indian Cricketer)

Sprint Retrospective: The Sprint Retrospective provides an opportunity to inspect what went well and what can be improved in the sprint, as well as identify next steps to work on. The main objective of the Sprint Retrospective is to:

• Identify how the sprint went in terms of work, people, processes, tools, technology, product, and relationships. This is a safe space to raise anything that is not working and also an opportunity to recognize what is working well.
• Create a set of next steps to sustain what is working well and improve areas that need it.

I wanted to share with you some thoughts on sprint retrospective and planning. These are two key events in the Scrum framework that help teams to continuously improve and deliver better products.

Sprint retrospective is a time for the team to reflect on the last sprint and identify what went well and what needs improvement. It’s important to create a safe environment where everyone feels comfortable sharing their thoughts. We don’t want to play the blame game, but rather focus on finding solutions to the challenges we face.

To do this, I suggest using the “Sad, Glad, Had” method. Each team member shares what made them sad, what made them glad, and what they wish they had in the last sprint. This helps to identify areas of improvement and also celebrate successes.

It’s also important to create a set of next steps to sustain what is working well and address areas that need improvement. And we should review these next steps in each retrospective meeting to ensure we’re making progress.

One key area for improvement is the Definition of Done (DoD). If there were many defects in the last sprint, the team should come up with a plan to introduce test automation and improve code coverage as part of the DoD. This will help to deliver higher-quality products.

Sprint planning is a time for the team to come together and agree on a common goal for the upcoming sprint. The team collaborates to understand what needs to be done and decides what can be accomplished as a team.

The input for this meeting is the Product Backlog, which is simply a list of product features. The development team should make a genuine attempt to identify what can be achieved and come up with a sprint goal that can be released to the user, just like a feature.

It’s important to consider the team’s velocity, which is not a measure of productivity, but rather a tool to forecast more accurately. And we should be mindful of the team’s capacity and allocate a buffer for unexpected events such as production defects, unplanned leaves, and unmanaged risks. This will help to ensure we’re delivering on time and with high quality.

In conclusion, these events are crucial for the success of the team and the product. By continuously improving and working towards a common goal, we can deliver better products and create value for our customers.