Role

Scrum master

Who notices first that a task has been stuck for three days - the team at the stand-up, or nobody? The answer says whether obstacles are removed or waited out.

Intro call

Four questions we would start with

Who notices first that a task is stuck?

If nobody does until the next meeting, obstacles are removed at the rhythm of meetings rather than at the rhythm of the work.

What do you drop first when an iteration falls apart?

Usually the retrospective - the only place where it could be established why it is falling apart.

How many times has the same obstacle come back in the last three iterations?

If you do not know, the improvements concern what somebody remembers rather than what costs the most.

Where do the retrospective's conclusions go?

If they go onto a board nobody comes back to, the retrospective is a conversation rather than a mechanism for change.

Team area, a board: a person at the board with the sticky notes, the team at the table seen from behind.

We take over the chasing and the collecting, you keep the work with the team

Tracking the flow, collecting obstacles, preparing the material for a retrospective and chasing the actions can be taken off the desk. The work with people and recognising what is really blocking stay with the scrum master.

  • A stuck task reports itself. - Before the stand-up rather than at it - because then the obstacle lives one day rather than three.
  • Obstacles have a register and a history. - Recurrence is visible, so the conversation with the organisation is about a pattern rather than a single case.
  • The retrospective gets material, not a blank page. - The data about the iteration is prepared, so the time goes on the conversation about causes.

Scope

What can be taken off a scrum master

Twenty example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to how your teams work.

How the iteration runs

  • The state of the tasks in the iteration without asking the team
  • A signal when a task has not changed status for longer than agreed
  • Pointing out tasks coming back from review
  • The scope added during the iteration

Obstacles and their removal

  • A register of obstacles with an owner and the date raised
  • A signal when an obstacle has been open longer than agreed
  • Pointing out obstacles that recur between iterations
  • Escalation outside the team (decision: the scrum master)

Team meetings

  • Material for the stand-up: what moved, what is stuck
  • Preparing the iteration review with the scope delivered
  • A summary of the topics raised by the team
  • A register of what was agreed at meetings

The flow of work

  • The time a task takes through each stage
  • Pointing out the stage where tasks wait longest
  • Work in progress against the agreed limits
  • Comparing forecasts with delivery (assessment: the team)

Retrospectives and improvements

  • Material for the retrospective from the iteration data
  • A register of actions with a date and an owner
  • A reminder about an action with no progress
  • A summary of the actions delivered and abandoned

A day's work

Today

  • You establish the state of tasks at the stand-up, asking one by one
  • You learn about a stuck task when somebody mentions it
  • You write obstacles in notes and chase them from memory
  • You do not know which obstacle comes back every iteration
  • The retrospective starts with gathering impressions
  • The retrospective's actions are lost within two weeks

With AI assistance

  • You have the state of the tasks before the stand-up, so the conversation is about causes
  • A task with no movement reports itself
  • Obstacles have a register, an owner and a time open
  • Recurring obstacles are pointed out as a pattern
  • The retrospective starts from the iteration data
  • The actions have a date and remind themselves
  • Time to remove an obstacle

    an obstacle lives a day rather than until the next meeting

    a stuck task reports itself

  • Predictable delivery

    fewer iterations ending in a surprise

    the flow and the scope added are visible

  • The quality of retrospectives

    the conversation is about causes rather than about gathering facts

    the material is prepared beforehand

  • Time in meetings

    shorter stand-ups with the same knowledge

    the state of the tasks is known before the meeting

We start with obstacles, because they cost the most and are the easiest to see.

  1. Step 1

    A register of obstacles with the time open

    Who raised it, what it blocks, since when it has been open.

  2. Step 2

    Signals about stuck tasks

    A task with no status change reports itself before the meeting.

  3. Step 3

    Material for the meetings

    The state before the stand-up, the scope and the flow before the review and the retrospective.

  4. Step 4

    Recurrence and actions

    Obstacles that come back and what became of the retrospective actions. Last, because it needs several iterations of history.

Common questions

Questions that come up at the first meeting

How is this different from a project manager?

A project manager is accountable for scope, dates and reporting outwards. A scrum master is accountable for the team being able to work - and has no authority over it. That is a completely different position and different levers.

Does this fall under the AI Act?

Supporting a team's work is not a high-risk use, but it is an area where the line is easily crossed. Data about the flow of work attributed to people and used for assessment would be employee monitoring. Our recommendation is unambiguous: the scope stays at the level of tasks and stages, never at the level of people.

Still have a question that is not here? Book a call

Next step

Which obstacle came back in your last three iterations?

We will show you what a scrum master's work looks like when a stuck task reports itself and the retrospective starts from data.