This guide helps US college students prepare a senior capstone presentation. It includes a timed outline, sample wording, a worked results example, and preparation checks. The main example uses a software prototype, with adaptations for research and other disciplines.
About this guide: The recommendations combine cited university guidance with illustrative planning examples. The reservation prototype, test observations, and sample scripts are fictional teaching examples—not findings from a real student project or a study of presentation outcomes.
Jump to: Presentation outline · Results-slide example · Demo preparation · Questions and answers · Final checklist
1. Confirm the Requirements and Audience
Before creating slides, confirm the speaking time, whether Q&A is included, required sections, slide limits, submission format, and demonstration rules.
There is no universal capstone presentation length. Appalachian State University’s March 2025 MPA Guide to Success describes approximately six minutes and a maximum of five slides. Kansas State University’s CIS 598 guidance describes roughly 30–45 minutes. These are program-specific examples; follow your own current assignment brief.
Next, identify your audience. A specialist faculty panel may need detailed justification of methods. Classmates or industry guests may need unfamiliar terms explained before they can interpret your findings.
Use this preparation map:
| Requirement | Material to prepare |
|---|---|
| Explain the problem | A documented need or research question |
| Define the evaluation | A research question and evaluation plan, or an objective with observable acceptance criteria |
| Justify the approach | Alternatives and reasons for your choice |
| Demonstrate achievement | Findings, test records, or prototype behavior |
| Evaluate limitations | What remains uncertain and why it matters |
| Explain ownership | Specific responsibilities and supporting records |
For a prototype or deliverable, an acceptance criterion is an observable condition used to judge whether a requirement has been met. Define it before evaluating the result.
For exploratory research, explain the research question, analysis approach, and limits on interpretation. A finding does not need to support the original expectation to be informative. Disclose changes to your evaluation plan and explain why they were necessary.
If your objectives are unclear, revisit your capstone project proposal.
2. Build a Timed Capstone Presentation Outline
For a ten-minute speaking slot with Q&A afterward, this example allocates nine minutes to planned explanations and one minute to transitions, demo navigation, or minor delays.
These timings are planning suggestions, not assessment rules.
| Slide | Main purpose | Planned time |
|---|---|---|
| 1 | Title, presenter or team, and project purpose | 20 seconds |
| 2 | Problem and affected users | 50 seconds |
| 3 | Objective or research question, scope, and evaluation | 40 seconds |
| 4 | Method and reasons for choosing it | 60 seconds |
| 5 | Design or research process | 50 seconds |
| 6 | Demonstration or worked example | 100 seconds |
| 7 | Results and interpretation | 100 seconds |
| 8 | Limitations and lessons | 50 seconds |
| 9 | Individual contributions | 30 seconds |
| 10 | Conclusion and next step | 40 seconds |
| Planned explanations | 9 minutes | |
| Buffer | Transitions, navigation, or minor delays | 1 minute |
For an individual project, use your name and role instead of team details. Use the contributions section to distinguish your work from external tools, datasets, libraries, or other assistance.
If questions count toward the assigned slot, reserve their time first. A ten-minute session with three minutes reserved for questions leaves seven minutes for the talk, including transitions.
For a shorter presentation, combine related sections and reduce background. For a longer presentation, expand evaluation, alternatives, and interpretation rather than adding more feature screenshots.
Cite borrowed figures, data, and ideas on the slide where they appear, using your course’s required format. Keep full references, additional calculations, and detailed diagrams in appendix slides if permitted. Evidence needed to understand your main conclusion belongs in the core presentation.
3. Introduce the Problem Before the Technology
Open with the problem, who it affects, your project objective, and what the audience will see.
Sample opening for the fictional reservation prototype:
“Our project examines how a campus equipment desk could manage reservations without conflicting bookings. We built a prototype that checks availability before confirming a reservation. Today, we’ll explain the design, demonstrate the booking workflow, and show what our tests establish.”
Adapt this wording to your actual work. Do not imply that you interviewed users, deployed a system, or measured an improvement unless you did.
Then state the project boundary. For example, explain that university account integration was outside scope if that exclusion affects how the audience should interpret the prototype.
4. Give Each Slide One Clear Job
Each slide should help the audience understand a finding, decision, or step in your argument.
Replace vague titles with informative ones:
| Vague title | More useful title |
|---|---|
| Database | Availability is checked before confirmation |
| Methodology | Why we selected this approach over the alternative |
| Results | Selected booking checks matched the expected outcomes |
Use a diagram for relationships, a chart for measured comparisons, and an annotated screenshot for a workflow. Use a results headline only when your evidence supports it.
Keep text readable on the presentation display. Label chart axes and units, use strong contrast, and avoid conveying meaning through color alone. Explain important visual details aloud.
For research projects, a key figure may replace the software demonstration. Business projects can show a recommendation and its assumptions. Engineering projects can connect prototype behavior to test conditions.
5. Connect Results to the Evaluation Plan
A useful results slide shows how the evidence answers your research question or relates to your project’s acceptance criteria.
Worked example: preparing a results slide for a fictional reservation prototype
All observations below are invented teaching examples, not findings from a real student or FileMakr project.
Objective: Prevent overlapping reservations for one uniquely identified item while allowing bookings that do not conflict.
Acceptance criterion for these checks: Reject an overlapping booking for the same item; accept a non-overlapping booking or a booking for a different available item.
Assumptions: Each item serves one reservation at a time. All requests satisfy other booking requirements. An existing reservation for Item A runs from 10:00–11:00 on the same day. Under this example’s booking rule, a reservation may begin exactly when another ends.
Each check starts independently from that same baseline.
| Requested booking | Expected outcome | Fictional observation |
|---|---|---|
| Item A, 10:30–11:30 | Reject: overlaps existing booking | Rejected |
| Item A, 11:00–12:00 | Accept: starts when existing booking ends | Accepted |
| Item B, 10:30–11:30 | Accept: different available item | Accepted |
Conditions: Local prototype, fictional data, sequential requests.
Bounded conclusion: The fictional observations satisfy the acceptance criterion for these three selected checks.
Limitation: Simultaneous requests from multiple users were not evaluated. These checks do not establish production reliability.
What belongs on the slide?
Do not place this entire worked example on one slide. Separate the audience-facing content from your explanation and supporting records.
| Location | Content |
|---|---|
| Displayed slide | Headline: “Selected booking checks matched the expected outcomes”; the three-row results table; the note “Sequential checks only; simultaneous requests not tested” |
| Spoken explanation or speaker notes | Objective, acceptance criterion, starting state, booking assumptions, and interpretation |
| Appendix | Detailed test inputs, logs, environment details, and additional checks; summarize any failures that affect the main conclusion in the core presentation. |
Sample spoken explanation for the fictional results slide:
“The observed behavior matched our expected outcome in each displayed check. Each check started from the same baseline. That supports a narrow conclusion about these scenarios. We have not evaluated simultaneous requests, so we cannot claim the system prevents conflicts under concurrent use.”
For your own presentation, show actual inputs and outcomes. Summarize failures that change your conclusion in the main presentation, and keep detailed logs in the appendix. Explain how the results relate to the evaluation plan. Selected examples are not a complete test suite.
For quantitative research, identify the sample, metric, comparison, and relevant conditions. For qualitative work, explain how observations were collected and interpreted.
A demonstration shows selected behavior. Evaluation explains what the evidence establishes under stated conditions.
Check that your presentation’s numbers and conclusions match your final project report.
6. Prepare a Focused Demo and Backup
Demonstrate one workflow that supports an important objective. For the fictional reservation example, show an available booking and then an attempted conflict.
Before presenting:
- Prepare fictional or approved demonstration data.
- Reset the application to a known starting state.
- Test accounts, permissions, and required services.
- Close private tabs and disable notifications.
- Prepare a permitted recording of the same workflow.
- Keep screenshots and slides available offline.
Choose your backup-switch rule during rehearsal. For example, if the first planned recovery attempt fails, move to the recording rather than spending the remaining presentation troubleshooting.
Sample recovery wording:
“The live demonstration is not working as expected, so I’ll switch to the recorded version of the same workflow.”
Name the cause only if you know it. Clearly identify recordings, and remember that a backup video does not automatically satisfy a live-demo requirement.
7. Rehearse Delivery and Team Handoffs
Rehearse aloud with the actual slides and demonstration. Silent review will not reveal lengthy explanations, navigation delays, or awkward handoffs.
| Practice pass | Completion check |
|---|---|
| Content | A listener can explain the problem, main result, and limitation |
| Timing | For the example outline, planned explanations fit nine minutes; the full rehearsal, including transitions and demo navigation, stays within ten minutes |
| Recovery | You can switch to backup material and continue explaining |
Adjust the timing check to your assigned slot. If transitions use more than the planned buffer, shorten the explanations rather than assuming you will speak faster on presentation day.
If you run long, cut repeated background and optional implementation detail before removing the evidence supporting your conclusion.
Pause after stating a major result. Face the audience when explaining a slide, and use short notes to recover your place instead of reading paragraphs.
For teams, assign sections by substantive responsibility and course requirements. Practice transitions such as: “Jordan will now explain how we evaluated that design.”
Sample contribution statement for a fictional project team:
“I implemented the reservation checks and prepared the associated test cases. Jordan developed the interface and integration tests. We reviewed the final results together.”
Keep supporting task records available. Do not claim another team member’s contribution as your own.
8. Prepare Answers About Decisions and Evidence
Practice explaining:
- Why you chose the problem.
- Which alternatives you considered.
- How you evaluated the work.
- What the evidence does not establish.
- What you personally contributed.
- What you would change next.
Answer the question directly, then give the reason, supporting evidence, and relevant boundary.
Sample question for the fictional reservation prototype: How do you know it prevents conflicting reservations?
Sample answer for the fictional reservation prototype:
“Our selected checks show that the prototype rejected an overlapping booking for the same item while allowing the two non-conflicting bookings displayed. These were sequential requests. We have not tested simultaneous requests, so the results do not establish that every possible conflict is prevented.”
If a question is unclear, ask which condition or decision the panel wants you to address.
If you do not know, explain what you did not investigate and what evidence would be needed. Do not invent a result.
For broader technical-question practice, use FileMakr’s project defense preparation guide.
9. Close With the Main Finding and Next Step
End by stating what the project achieved or found, the most important limitation, and the next justified action. Avoid introducing a new feature or unsupported claim.
Sample closing for the fictional reservation prototype:
“Our prototype demonstrates the reservation workflow within the scenarios we tested. The selected checks matched the expected booking rules. Reliability under simultaneous use remains unverified, so our next step would be concurrency testing. We welcome questions about the design and evaluation.”
Keep a concise summary visible during questions so the audience can refer to your main conclusion.
10. Adapt to the Presentation Format
| Format | What to change |
|---|---|
| In person | Check the display, microphone, adapters, and visibility from the back of the room |
| Live online | Test screen sharing and audio; keep another presenter ready to share the deck if permitted |
| Recorded | Check the required format, captions, audio clarity, and final exported file |
| Poster session | Prepare a brief overview and a longer explanation; use a clear reading order |
For online sessions, check that you are sharing the intended window and that presenter notes remain private. Follow institutional accessibility requirements.
For submitted recordings or slide files, open the uploaded version—not only the local original. Check playback, captions, links, sharing permissions, and any required filename or file-size limit. Where permitted, test viewer access without relying on your owner account.
Common Capstone Presentation Mistakes
| Mistake | Why it weakens the presentation | Correction |
|---|---|---|
| Reading report paragraphs | Makes the audience read instead of follow your explanation | Use a focused visual and explain its meaning |
| Demonstrating every feature | Uses time needed for results | Select a workflow tied to an objective |
| Claiming success without explaining evaluation | Makes the conclusion difficult to assess | State the criteria or research approach, then show the evidence |
| Hiding failed or incomplete work | Misrepresents project status | Explain the outcome and its consequences |
| Troubleshooting indefinitely | Consumes the remaining presentation | Follow your backup-switch rule |
| Giving vague contribution answers | Makes ownership unclear | Describe specific responsibilities |
Final Preparation Checklist
Content and delivery
- Every required rubric criterion has a place.
- The research question or project objective is clear.
- Evaluation methods and applicable acceptance criteria are explicit.
- Conclusions match the submitted report.
- Claims identify supporting evidence, conditions, and limitations.
- Borrowed figures, data, and ideas are credited where used.
- Required AI-use disclosures are included.
- Speakers know their responsibilities and handoffs.
- The full rehearsal fits the assigned time.
Equipment and files
- Slides and backups open on the presentation device.
- Demo accounts and permissions work.
- Notifications and private windows are closed.
- Recordings have clear audio and appropriate captions.
- A permitted offline backup is available.
- Uploaded files, playback, links, and viewer permissions have been checked.
Frequently Asked Questions
How many slides should a capstone presentation have?
Follow your course’s slide limit. If none is specified, use the ten-slide outline here as a starting point for a ten-minute talk, then adjust after rehearsal. Slide count alone does not determine pacing.
Can I present a capstone that is not fully complete?
Follow your course’s submission requirements. Distinguish completed, partially completed, and planned work. Explain how unfinished work limits your conclusions without presenting expected outcomes as achieved results.
What if my results do not support the original objective or expectation?
Report the result accurately. Explain the evaluation, possible reasons, and implications. A research finding can be informative without supporting the original expectation. For deliverables, identify unmet requirements and their consequences. Assessment depends on your rubric.
What should I put on the final slide?
Show the main supported conclusion, an important limitation, and the next step. Keep the summary concise enough to remain useful during questions.
Should I include source code in the presentation?
Include a small, readable excerpt only when it helps explain an important decision or your rubric requires it. Keep larger code sections available for questions.
Can I use PowerPoint, Google Slides, or a template?
Use the tool and format your course permits. Replace sample content with your own work, credit external assets, and test the exported presentation on the intended device.
How should I handle presentation nerves?
Practice the opening and transitions aloud, use brief cue notes, and rehearse once for another person. If you lose your place, pause, look at the slide’s main point, and continue from that idea.
Your Next Step
Write three sentences before building the rest of your deck:
- What did the project achieve or find?
- What evidence supports that conclusion?
- What remains untested, uncertain, or incomplete?
Check those answers against your objective or research question and evaluation plan. Use them to choose your slides and demonstration.
For additional workflow examples, explore FileMakr’s project demos. Use external resources according to your course rules, and present your own work and contributions accurately.
