Skip to content
CS Capstone Handbook

Presentations

Sooner or later you’ll stand in front of people who need something from your work: a sprint demo for the people who asked for the feature, an update for a stakeholder deciding whether the project is on track, a design review where your peers try to break the design before you build it. This page covers how to structure each of those talks, how to design slides that carry an argument, and how to run a live demo that survives the room. It doesn’t cover writing documents or how to run the sprint itself.

Every section below serves one goal: leave the audience with an accurate understanding of what matters most. When you’re unsure whether something belongs in a talk, keep it only if it serves that understanding, because that’s the part of the talk the audience will act on after you’ve left the room.

Two teachers of technical communication are worth knowing by name. Jean-luc Doumont, author of Trees, Maps, and Theorems, separates information (what) from a message (so what), and builds his approach to communication, presentations included, on three laws: adapt to your audience, maximize the signal-to-noise ratio, and use effective redundancy. Patrick Winston’s How to Speak, an MIT tradition for over 40 years and recorded in full, treats speaking as something you improve by learning a small set of heuristic rules rather than a talent you have or lack. If you watch one thing before your next talk, make it that hour, because his rules come with examples of their use in job talks, thesis defenses, oral exams, and lectures.

Sprint Demos

Section titled “Sprint Demos”

A sprint demo is a live walkthrough of what the team delivered in the most recent sprint: working software, experimental outputs, or validated findings, shown running. A list of closed tickets is a status report, and the audience can read one on their own time; the demo is the one moment they see the work behave.

A good sprint demo:

  • Shows the work end to end on realistic data, rather than describing what was attempted or what’s planned next.
  • Shows work that meets the team’s Definition of Done. If “done” means deployed to staging, run the demo on staging; if it means passing tests locally, a local demo is fine.
  • Connects what was built to a requirement or acceptance criterion the audience already knows.
  • Says plainly what was descoped, delayed, or changed, and why.
  • Ends with a question for the audience: “Does this meet your expectations? What should we change?”

The demo is the team’s main feedback loop with the people it builds for, and it sits in the review step of the sprint cycle. Whoever is in the room, run it as a conversation rather than a performance, because the feedback you need only arrives if the audience has room to give it. Leave the last five minutes for the audience’s answers, and write them down before anyone leaves, so the team plans the next sprint from the same notes.

Stakeholder Presentations

Section titled “Stakeholder Presentations”

A stakeholder presentation addresses a broader audience: people who care about the project’s outcome but aren’t involved in the day-to-day work. That includes leadership, management, cross-functional teams, the people who fund the work, and anyone evaluating the project from the outside.

Where a demo says “here’s what we built this sprint”, a stakeholder presentation says “here’s where the project stands, how we got here, and where it’s going.” Cover four things, in this order, because each one answers the question the audience asks next:

  • The problem: what the project solves, and for whom. This grounds the audience before any technical content.
  • The approach: how the team decided to solve it, and which alternatives it considered and rejected. Showing the rejected options is what tells the audience the choice was deliberate.
  • The current state: what has been built, validated, or discovered so far. Show it: a working demo, a plot of real results, or a walkthrough of the running system convinces more than a summary of tasks completed.
  • What comes next: the known limitations, the risks that remain, and the plan for the next phase.

At least one large company has decided that slides are the wrong medium for this altogether. In his 2017 letter to shareholders, Jeff Bezos writes that Amazon doesn’t use slide presentations in its meetings. Instead, someone writes a six-page narrative memo, everyone reads it silently at the start of the meeting in what he calls a kind of “study hall”, and the discussion follows. He adds that a great memo “probably should take a week or more”, because it’s written, reviewed by colleagues, set aside, and rewritten. You’ll almost certainly be asked for slides rather than a memo, but borrow the habit anyway: write the argument as paragraphs first, check that it holds together, and only then decide which parts need a slide, because prose won’t let you skip the connection between two claims the way a bullet list will.

Design Reviews

Section titled “Design Reviews”

A design review is a presentation to peers (teammates, advisors, anyone qualified to critique the approach) before the team commits to it. It applies to more than architecture and code: UI designs, data models, research methods, and workflow proposals all benefit from structured critique while changing them is still cheap.

The purpose is to stress-test the design, and that works best with a written technical design to react to rather than a verbal sketch. Present the problem, the options you considered, the one you chose, and its consequences, then ask for objections. A problem found in the review costs a conversation; the same problem found during implementation costs the code already built on top of it.

Treat hard questions as help. If a review produces no changes at all, ask whether the design is really that mature or whether nobody in the room felt able to object, and next time ask one reviewer in advance to argue for the option you rejected.

Public Demonstrations

Section titled “Public Demonstrations”

Some presentations happen in open, public settings: expos, showcases, poster sessions, or employer events. These work differently from a team-internal or classroom presentation, because the audience chooses itself, arrives in the middle of your explanation, and leaves whenever it wants.

What changes:

  • The demo leads. Have it running before the doors open, looping or ready to restart, and show visitors the thing working before you explain it.
  • The audience is mixed. Some visitors are deeply technical and many aren’t. You need an explanation that works for both, and the running software is the part both understand.
  • You don’t control the timing. Someone may walk up at any moment, so be ready to start without notice.
  • Attention is short. Keep a 60-second pitch ready for visitors who won’t stop walking, and end it by pointing at the running demo, so the ones who stay see the work.

Principles That Apply to Every Presentation

Section titled “Principles That Apply to Every Presentation”

The habits below hold whatever the format, from a five-minute sprint demo to a conference talk.

Lead with the Point

Section titled “Lead with the Point”

Don’t build to a conclusion; start with it. “This sprint we shipped user authentication and onboarded our first external tester” is a stronger opening than three slides of context, because the audience knows what to listen for in everything that follows.

The rule applies at every level: the presentation as a whole, each section, each slide. If someone walked in halfway through and saw only the current slide, would they understand the point it makes?

Show, Don’t Tell

Section titled “Show, Don’t Tell”

If you can show something working, show it rather than describing it. A running feature answers questions a slide about it can’t, such as how fast it responds and what it does with bad input. Reserve slides for what you can’t demo: architecture diagrams, risk tables, timelines, before-and-after comparisons, data visualizations.

If what your project produces is a result rather than a feature someone uses, showing means displaying real outputs: plots, model performance metrics, pipeline results on actual data. A Jupyter notebook with real outputs convinces more than a slide summarizing what the notebook produced, because the audience can see the numbers came from code that ran.

Design for Your Audience

Section titled “Design for Your Audience”

Technical presentations to peers can include architecture diagrams, code snippets, and implementation detail. Stakeholder presentations usually shouldn’t. Before you keep a slide, ask whether a non-engineer in this audience would understand it.

The same project often needs both versions. A sprint demo for the people who asked for the software focuses on functionality and outcomes; a design review with the team focuses on architecture and trade-offs.

Let Ownership Guide Who Speaks

Section titled “Let Ownership Guide Who Speaks”

The person closest to a piece of work should be the one who explains it. Divide the talk by ownership (the person who built the feature explains the feature, the person who ran the experiment presents the results) rather than splitting it evenly by slide count, because the owner can answer the follow-up question without handing it back to a teammate.

Prepare for Questions

Section titled “Prepare for Questions”

Before the talk, list the questions you expect and rehearse the answers. The hard questions in technical presentations are predictable:

  • “Why did you choose X instead of Y?”
  • “What happens if this component fails?”
  • “How does this scale beyond your current usage?”
  • “What’s the biggest risk right now?”

You don’t need perfect answers. “We considered that and chose not to, because…” and “We don’t know yet, and here’s how we plan to find out” are both credible. What damages trust is a question that shows nobody on the team thought about it at all.

Delivering a Demo

Section titled “Delivering a Demo”

A live demo can fail in more ways than a slide deck can (the network, an expired account, a database someone reset), so most of the work happens before you’re in the room.

  • Use realistic data. Obviously fake data (“Test User 1”, “Lorem ipsum”, “AAAA”) makes the audience wonder what else isn’t real. Populate the demo environment with data that looks like the real thing.
  • Know the path. Practice the exact sequence of interactions: what you’ll click, what you’ll type, and what the system will show in response.
  • Have a fallback. Record a video of the demo before the presentation. If the live demo breaks, play the recording and keep talking; the audience still sees the feature work.
  • Narrate as you go. Don’t click through screens in silence. Say what you’re doing and why: “I’m logging in as an admin and opening the project dashboard, where you can see the new analytics view.”
  • Leave the demo visible. After the walkthrough, keep the application or notebook open rather than switching back to slides, so it’s there for follow-up questions.

Recorded vs. Live Presentations

Section titled “Recorded vs. Live Presentations”

Each format needs different preparation.

For recorded presentations:

  • Use a quiet room with consistent lighting.
  • If you include a face camera, keep it small and in a corner, because the screen content is what the viewer needs to read. OBS Studio is free and cross-platform; Loom and Zoom’s computer recording are quicker to set up if you only need one take.
  • Edit out dead air and false starts. A viewer can skip ahead, but every skip is a moment they stopped listening.
  • Speak slightly slower than feels natural, because a recording can’t slow down for a confused viewer the way you would when you see faces in the room.

For live presentations:

  • Practice the full run-through, including the handoffs between speakers, at least once on the setup you’ll use. The TEDx organizer guide goes much further: it tells organizers that speakers will rehearse “for weeks or months in advance”, including a dress rehearsal, and should go through the talk several times onstage with their slides.
  • Confirm the technical setup (display resolution, audio, browser, microphone) on the actual machine and screen you’ll use.
  • Arrive early. A problem found five minutes before you start is an emergency; the same problem found thirty minutes before is an inconvenience.

Slide Design

Section titled “Slide Design”

You don’t need design expertise to make effective slides, but you do need a position on what a slide is for. PowerPoint’s default layout, a topic phrase over a box of bullets, is the most common one: the estimates Garner and Alley (2013) cite from their own earlier surveys range from 65% of slides in engineering and science talks to 80% of the instructor slides supplied with introductory psychology textbooks. That layout puts on the screen the same words that are coming out of your mouth, and multimedia-learning research finds that this seems to reduce the working memory the audience has available (Garner and Alley, 2013).

The alternative is the assertion-evidence structure, which Michael Alley at Penn State documents, with templates, at assertion-evidence.com. Each slide gets a headline that states a complete sentence rather than a topic (“Latency doubles above 200 concurrent users”, not “Performance”), and the body of the slide is the visual evidence for that sentence: a chart, a diagram, a screenshot. The bullets disappear because the headline carries the claim and the image carries the support. It takes longer to build, and it exposes a vague slide immediately, because a sentence headline has to say something.

It’s also slide advice that has been tested as a whole structure. Earlier studies had mostly tested single features of a slide, such as how dense the text was or whether an image matched it, and Garner and Alley (2013) set out to test a complete template. They randomly assigned 110 engineering undergraduates, recruited from a communications course, to watch the same narrated presentation on MRI, with either assertion-evidence slides or slides built on PowerPoint’s defaults. The assertion-evidence group wrote essays that showed better comprehension and fewer misconceptions, reported less mental effort, and scored higher on an unannounced recall test given later. On the immediate multiple-choice test the two groups did about equally well on facts; the difference showed on the questions that required inference (Garner and Alley, 2013). That’s one study, on one topic, with students as the audience, so treat the size of the effect as uncertain; the direction is the reason to try the structure.

With that settled, the rest is mechanical:

  • One idea per slide. If a slide makes two separate points, split it. A headline that needs the word “and” is usually two slides.
  • Diagrams over prose. A system architecture diagram, a data-flow visualization, or an experimental workflow communicates more than three paragraphs of description, and the audience can look at it while you talk.
  • Readable type. Use at least 24pt for body text, because a slide that’s readable on your laptop is often unreadable from the back of a room. Check contrast rather than trusting your monitor. At 24pt your text counts as large under the WCAG contrast minimum, which only requires 3:1, but design against the 4.5:1 it sets for normal-size text anyway, as a deliberate margin: a projector in a bright room washes out colors further than any screen you tested on.
  • Attribute borrowed assets. If you use an image, icon, or diagram you didn’t create, include a source credit, for the same reason you’d cite a source in writing.

Best Practices

Section titled “Best Practices”
  • Time yourself, because running well over your slot takes the time from whoever speaks next, and the part you rush at the end is usually the conclusion.
  • Get feedback from someone outside the team before the final delivery, because they’ll catch the jargon and skipped steps the team no longer notices.
  • Name each handoff out loud (“I’ll hand it over to Sam, who will walk through the data pipeline”), because it tells the audience a new section is starting and who to direct questions to.
  • Send a short written summary afterward, because the people who have to act on the talk will want the decisions and risks in writing.

Some Truths About Presentations

Section titled “Some Truths About Presentations”

Craft advice and tested advice aren’t the same kind of claim. “Make eye contact” and “never read your slides” are craft advice, passed on by people who teach speaking. The assertion-evidence structure has a controlled comparison behind it (Garner and Alley, 2013), with the limits described under Slide Design. Both can be useful, but when a piece of craft advice doesn’t fit your audience or your material, you have less reason to hold on to it than to the tested one.

What an audience approves of and what it learns from can come apart. In Garner and Alley’s study, the students who saw bullet-heavy slides rated the amount of text on them as more appropriate than the assertion-evidence group rated theirs, while learning less from them (Garner and Alley, 2013). “The slides looked right” tells you the audience was comfortable, so when you want to know whether a talk worked, ask the audience what they’d do next or how they’d explain the result to someone else.

Rehearsal is easy to skip, because it’s boring and tweaking slides feels like work. The failures it prevents are specific: demos break on the machine, the adapter, the resolution, the network, and the one account whose password nobody remembers. A rehearsal on your own laptop catches almost none of those. A rehearsal on the actual machine, projected onto the actual screen, catches most of them.

Disclose gaps by default, even ones you’re fairly sure nobody would notice, because the costs are lopsided. “This part doesn’t work yet, and here’s why” costs little and shows you know where the edges of your system are. Glossing over a gap and getting caught costs much more: once one claim turns out to be wrong, the audience has a reason to doubt every other claim in the talk. Build the habit in low-stakes demos, where the audience is judging how you work rather than deciding whether to fund the feature, so it’s already reflexive when a budget depends on the answer.

Finding presentations hard doesn’t mean you’re in the wrong field: being a strong engineer and being a strong presenter are separate skills. Winston’s lecture rests on the premise that speaking improves when you learn specific rules and practice them, so treat the difficulty as a pointer to where your practice time should go: rehearse the talks you’d rather avoid, and ask for feedback on the delivery as well as the content.

Presentations in Industry and Academia

Section titled “Presentations in Industry and Academia”

In industry, engineers present constantly: sprint demos, design reviews, incident postmortems, all-hands updates, sales engineering calls, and cross-team coordination meetings. Dropbox, for one, writes the skill into its published engineering career framework: Communication is among the expectations for its entry-level engineers (IC1) and its staff engineers (IC5), and at staff level the framework expects an engineer to tailor the message to the audience and present it “at the right altitude”.

Begel and Simon (2008) observed eight recent graduates for 85 hours during their first six months as developers at Microsoft and sorted the ways they got stuck into five kinds (communication, collaboration, technical, cognition, and orientation), only one of them technical. They concluded that the graduates’ degrees had given them adequate design and development skills, but hadn’t addressed communication, collaboration, and orientation as well. On communication, the new developers sometimes went into too much detail in design meetings, at other times gave too little, and didn’t push for enough detail in the answers they got back, which is the “design for your audience” problem above, observed in the field.

In academia, conference talks and thesis defenses follow the same principles; where they differ from industry talks is in what counts as evidence. An industry stakeholder wants to see the thing working; a conference audience wants to see the method and the numbers that let them judge whether it generalizes. A project shown at a public showcase, such as a university expo or a trade fair, often needs both, because the people walking past include practitioners who want a demo and researchers who want a method.

References

Section titled “References”
  • Garner, J. K., and Alley, M. P. (2013). How the Design of Presentation Slides Affects Audience Comprehension: A Case for the Assertion-Evidence Approach. International Journal of Engineering Education, 29(6), 1564-1579. https://writing.engr.psu.edu/ae_comprehension.pdf
  • Begel, A., and Simon, B. (2008). Struggles of New College Graduates in Their First Software Development Job. Proceedings of the 39th SIGCSE Technical Symposium on Computer Science Education, 226-230. https://doi.org/10.1145/1352135.1352218

Additional Readings

Section titled “Additional Readings”

Sources and further reading

Activities that exercise this