Daily standup

The regular communication heartbeat of every team. Short, concise, and focussed collaboration time, which is essential for successful delivery.

Objective

Share delivery progress across the sprint team members to identify dependencies, conflicts, constraints in order to minimise delivery delays.

Participants and Responsibilities

  • Team Lead
    • Schedule the meeting and manage the participant list
    • Host the meeting and run the agenda
    • Delegate running the meeting to another team member in their absence
  • Sprint Team Members
    • Provide individual team updates as invited by the Sprint Team Lead
    • Speak up to identify any dependencies, conflicts, constraints, or delays that may affect the team or individual’s ability to deliver the committed sprint work.

Scheduling

Daily standup should take place every working day of the sprint. Usually it is scheduled at the start or end of the working day. For geographically distributed teams this may not be feasible, and standup can be held at a regular agreed time.

Example Agenda

  1. Team lead confirms participants and shares any member absences (sickness or leave)
  2. Team members provide a short overview of their work, covering:

    1. What they did in the prior working day
    2. What the hope to accomplish in the coming working day
    3. Their blockers: any factors which will affect their ability to deliver the coming day’s work
  3. Team lead reviews the sprint burndown/up chart and leads a short team discussion regarding risks to committed work and the correctness of work item states.
  4. Team lead reviews any new bugs raised with the team. Bugs should be logged in work item management.
  5. Team lead confirms:

    1. Any actions required to “unblock” team members
    2. Their actions to communicate/escalate risks to committed work
    3. Any actions to add new tasks, update states and complete work
    4. Actions to contact workstream owners and request bug prioritisation, and agree whether these should be added to the sprint
    5. Any items to be considered at the next retrospective

Team Lead Guidance

The Team Lead is responsible for the effective running of the Sprint Daily Standup, and as such has a lot of latitude to run these recurring meetings as they see fit, including making exceptions to all the guidance below.

This guidance is included to help the Team Lead run the Standup effectively. Treating these as unbreakable rules is likely to be counter-productive, and the role of the Team Lead is to balance these principles to help their team deliver as effectively as possible.

  • Keep it short – standup should take no more than 15 minutes. If it is taking longer than this, it is likely that too much detail is being provided by team members.

  • Keep it focused – the purpose of the meeting is not to exhaustively detail what work has been done but rather identify causes of delay. If an issue has arisen, the team lead should schedule a separate discussion to resolve the issue. Standup is for identifying these delays, not resolving them.

  • Limit the audience – the Sprint Team should include individuals who have work item deliverables in the Sprint. It should not evolve into a general update forum for all stakeholders. The exceptions to this rule are the Product Owner and Delivery Managers, who may need to attend to understand critical delivery or process issues. However, it’s unlikely that they would need to provide updates on their individual delivery progress.

The participant list should be reviewed if updates or discussions are taking place on the call which detract from the meeting’s objective, which is to ensure delivery tasks proceed with minimum delay possible.

  • Take action immediately – after completing the standup it is likely that the team lead has a number of actions to unblock the team. These should be completed as soon as possible as they represent significant and immediate risk to the sprint team’s committed delivery.

  • Don’t replan – during a sprint, the committed work should not be changed. Once a sprint is planned, do not move stories to manipulate the burndown rate.

    Adding new tasks is fine, even if they weren’t anticipated in planning. However, the source of the unplanned work should be reviewed in the Sprint Retrospective.

    Refining estimates is also fine. Reasons for significant change should be reviewed in the Sprint Retrospective, and the “Original Estimate” preserved.

  • Keep it regular – avoid moving the meeting around. Standup is important and should not be moved to cater for attendees’ other commitments or one-off meetings. It should be regularly spaced (so that there is something to discuss!) and at a time that all Team Members are aware of.

Aborting a sprint

It is possible to abort an in-flight sprint, but the circumstances in which this is appropriate are (hopefully) rare.

  • DON’T abort the sprint if the committed work is unlikely to be fully delivered. The reasons for the team’s overcommitment should be evaluated in the next Sprint Retrospective, and unfinished tasks carried over (based on agreed priorities) for the next sprint.

  • DO abort the sprint if there is no work for the team to do, and there is insufficient clarity over the prioritised work in the backlog. A new Planning session is the only way to resolve the situation.

Edit this page on GitHub

The content on this page is published under Open Source licenses via GitHub. To submit issues or provide feedback please visit the repository.

Visit