stack twitter tryhackme rss linkedin cross

Wilco van Esch

Skip to main content

Search results

    How to make standups more useful

    Practical examples of how to recognise a less effective standup and how to improve:

    "Who wants to start?"

    Crickets chirp, time drags into eternity.

    Bad: wait for a volunteer to be the first to speak
    Better: call out a name, or pass around a microphone or other token
    Best: go from right to left on the board, whoever's assigned to the ticket should speak

    The three questions

    Instead of having individual contributors justify their time, focus as a team on what needs to happen.


    From person to person:

    "What did you do yesterday?"
    "What will you do today?"
    "Are there any impediments in your way?"


    Go from ticket to ticket (from closest to done to less close to done):

    "This is our current progress."
    "This is what we still need (to do)."


    Go from ticket to ticket (from closest to done to less close to done):

    "This is what we still need (to do) to get this done.
    "Who will explicitly commit to (code reviewing, rubber ducking, pair testing)?"
    "I'm ##% confident we'll get this done today."

    And "are we still aligned with the priorities and does anything in To Do need unblocking?"

    All of this helps keep people focused throughout and to think like an actual team.

    Waiting to discuss obstacles

    The (correct) notion that obstacles can be discussed in Standups and Retros means that some people wait for those occasions.

    Bad: Waiting for a ceremony to discuss being blocked or impeded by something.
    Better: Raising urgent blockers or impediments to a Scrum Master immediately.
    Best: Sorting out an urgent blocker or impediment with the relevant team members or stakeholders immediately.

    Note: there are times when raising an impediment with a Scrum Master is a better use of everyone's time than solving it yourself with the relevant people who can help. Use your best judgement.


    It's easy and natural for discussions to occur and for those discussions to take too long and not need everyone's attention.

    Bad: Using standups for freeform discussions on technical implementations, design walkthroughs, process improvements.
    Better: Nipping in the bud any meandering discussions and encouraging them to be continued afterwards in a smaller group.
    Best: Nipping discussions in the bud except where a problem could be most easily and quickly solved by the whole team right then.

    Being dead serious

    Every day's experience in agile software development teams affirms how much it matters for a team to be happy and communicate well with each other in order to do their best work.

    Bad: Discourage the wasting of time with joking around and silly distractions.
    Better: Encourage positive socialising among team members during standups.
    Best: Start the standup with casual banter, during the standup encourage/praise/thank others, end on an optimistic note.