Engineers are accidental presenters

Developers learn to build software. They do not learn to present it.

The sprint demo, or sprint review, is treated as a formality at the end of every sprint. The engineer who built the feature shares their screen and walks through it. The audience is usually non-technical stakeholders: product managers, executives, sometimes clients.

The engineer moves the way they always move. Fast. Deliberate. They know where everything is. The audience does not.

The cursor disappears into a compressed video feed. Navigation jumps between tabs without context. A calendar notification appears. The engineer dismisses it without breaking stride. The stakeholders have already lost the thread.

The problem is not the feature. The problem is what the audience can actually see.

What breaks during a sprint demo

The cursor is invisible. On screen share, the default cursor is compressed and hard to track. Stakeholders cannot tell where the presenter is pointing.

Notifications fire. Slack. Email. Calendar. The presenter has sound off. The notifications still appear on screen.

The wrong environment is loaded. Five tabs open: production, staging, a local build, documentation, two pull requests. It is not obvious which is active.

Browser zoom is inconsistent. Tabs zoomed in for debugging look wrong when shared. Text overflows. Layouts break.

The desktop is exposed. The engineer exits the browser to find a file. The audience sees the desktop. The professional framing breaks instantly.

Before the sprint demo: browser setup checklist

Do this in the five minutes before you share your screen.

  • Silence Slack and other chat apps
  • Close email and calendar. badge counts are still visible in the dock even when muted
  • Put your phone on do not disturb
  • Close every tab you do not need for the demo
  • Confirm you are in the right environment before sharing
  • Reset browser zoom to 100% on every open tab (Cmd+0 on Mac, Ctrl+0 on Windows)
  • Press Cmd+Shift+B (Mac) or Ctrl+Shift+B (Windows) to hide the bookmarks bar
  • Clear your desktop in case you exit the browser
  • Check mic and camera before the call starts

For the full version of this checklist, see The pre-demo checklist every solutions engineer should use.

During the demo

Slow down on navigation. Every tab switch is a context change for the audience. Pause after each one. Name where you are.

Make the cursor visible. A cursor halo renders a visible ring around the pointer during a screen share. If you are not using one, your audience is guessing at where you are pointing.

Confirm every click. A click highlight renders a brief ripple at the point of each click. This matters especially in dense UIs, dashboards, settings panels, data tables, where a click on the wrong element looks identical to the right one.

Navigate as a user, not a developer. Go through the UI the way a user would. If you take a shortcut, the audience loses the product logic that makes the feature make sense.

The work deserves to be seen

The sprint demo is the moment the team makes the case that what they built was worth the sprint. The code is already good. Make it possible to see that.

DemoFocus builds this checklist into your browser. Coming soon — sign up below.