Daily Standup Meeting Guidelines

This document provides a set of standards relating to standups which apply to people of all job roles.

Daily standup meetings are an opportunity to ensure that:

• The delivery team is aligned such that they are focused on delivering the prioritised work items that maximise business value.
• Any blockers / impediments impacting the delivery team are identified and addressed such that the team can meet the optimal pace / quality bar.

The following are some guidelines for running effective standup meetings:

1. The Scrum Master is responsible (and accountable) for scheduling and chairing standup meetings.
2. Standup meetings should be scheduled to last 15 minutes. However, while we have 15 minutes, they should ideally only take 10 minutes.

1. Standups should be attended by the delivery team (Developers, Test Engineers and the Scrum Master). The customer Product Owner does not attend.
2. Ideally, standups should be attended by a maximum of 7 people. If the team size exceeds this, consider splitting into multiple separate teams.

1. If the Scrum Master is not on the call, a meeting chair should be agreed at the start. This will generally be the project’s Technical Lead in most scenarios.

1. The chair should show the project board during the meeting (i.e. the Boards > Boards menu item in Azure DevOps). People should be talking about cards that we can see have status accurately captured on the project board. In general, we should be able to relate any items being discussed to in-flight items on the project board.
2. The benefit of showing the board is that this facilitates the identification of bottlenecks. As an example, if there are a large number of cards in QA Failed, this might prompt us to focus on rectifying QA failures rather than continuing with new feature development, to help unblock testing and to ensure the next release is prioritised.

1. If someone isn’t there at the start of the standup, start without them. Standups should wait for no one - and this includes the Scrum Master. It is the responsibility of each team member to ensure they attend and are punctual.

1. The Scrum Master / Chair should suggest the first person who speaks. This can be a different person each day.
2. Once someone has finished giving their update, they should nominate the next person to speak.
3. While someone is speaking, it is often useful for the Scrum Master / Chair to filter the board to show items Assigned To the person speaking to aid clarity.

The questions that each person should answer on a standup are:

1. What did you do yesterday?
2. What are you planning to do today?
3. Are there any blockers / impediments?

1. This is not a colleague’s opportunity to evidence that they were busy yesterday. The standup is:
   1. An opportunity to share updates that are relevant to other team members.
   2. An opportunity to confirm that this colleague is working in line with the project priorities as set out by the Scrum Master.
   3. Used to ensure that team members have a clearly defined runway of work and a plan for tackling blockers.
   4. Not used to describe the minutiae of tasks done yesterday. Details are only necessary in the case where there is a wider impact on the project or where there are blockers / a lack of clarity.
2. Updates should not include explanations of other projects or other work. If you were doing work on another project, or are planning to do work on other projects, you can simply mention the time commitment in terms of the impact it has on the project under discussion. As an example if the standup is for Project A.
   1. Do not say “I was working on a CRUD screen for Project B - I had a few challenges but it’s pretty much finished now.”
   2. Do say “I spent half of yesterday on another project and will be unavailable for Project A during the morning today.”
3. Some non-project-related discussion is permitted, but this should be strictly limited. If there are 5 people on the standup, then every 1 minute spent is worth 5 minutes in terms of project time. Non-project-related discussion should be limited to 2 minutes at start.
4. Don’t mention attendance at project meetings that everyone attended or will attend unless there’s a relevant update, since this adds no value.

1. For clarity:
   1. A blocker is something that is preventing delivery of the work items committed to during the sprint, or the sprint goal.
   2. An impediment is something that is slowing down delivery of the work items or could impact the team’s ability to deliver on the sprint goal.
2. Blockers should be tackled as a priority. This is preferable to simply dropping the current work item and moving on to the next one, since this helps ensure we delivery work items as per the business priority order.
3. It is perfectly acceptable to raise blockers pre-emptively to facilitate pro-active action. An example of this might be “I’ll be doing development on this today, however I’ll be setting up the environment to deploy it to tomorrow and I don’t currently have the Azure permissions required for this.”
4. It is worth noting that these are not necessarily personal blockers - they may be team blockers, or things that could impede others on the team. E.g.
   1. When a developer is updating configuration for an environment, it is worth giving others a heads that this may impact their testing.
   2. If a tester is starting a resource intensive automation pipeline run, they might highlight that this will block deployments for the rest of the team until complete.
5. If a blocker / impediment is identified, it may be worth adding a “Blocked” tag to the card, along with a note in the discussion section to describe what this is.
6. If a blocker / impediment is raised, the resolving / mitigating action should be agreed or taken offline for agreement. As always, the action should have:
   1. An owner.
   2. A target resolution date.
   3. If there’s any risk it could be forgotten, the action should be documented in the project’s Actions Log.
7. If the impediment is a general impediment, rather than something blocking current work, the Scrum Master may choose to:
   1. Arrange a separate meeting to review this outside of the standup.
   2. Record the impediment for further discussion during the sprint retrospective.

1. As an observation - blockers often emerge after searching questions are asked, rather than people proactively mentioning them in their initial update. This is likely a symptom of imposter syndrome and/or perceived expectations around ownership - people will often try and own their own issues, rather than asking others for support. This might be fine on some occasions, but often reaching out to other team members earlier rather than later will speed up overall delivery. Therefore, after the initial update is given, it is worth the chair or other team members asking searching questions where applicable.

1. If blockers are raised and these cannot be resolved immediately, the Scrum Master should agree a plan for discussing these further at some later time i.e. in this case they should not attempt to resolve them within this forum.