CS 472 Spring 2025 > Expectations for Status Updates
CS 472 Spring 2025
Expectations for Status Updates
General
Each week, your development team will give an in-class presentation on your ongoing project. Eleven of these will be informal; we will call them status updates. “Informal” here means that no special dress is required, professional-level delivery is not expected, and the presentations will not be recorded. However, you will need to be prepared with slides, plan in advance who is presenting what, and speak well.
Each status update will be a stand-alone presentation. Do not assume that your audience remembers earlier presentations.
Expected dates for the status updates can be found in the Semester Plan. If we run out of time on the announced date, then some presentations may be postponed until the next class meeting.
Requirements
Your presentation must include slides displayed on the classroom projector. Every team member must do some of the presenting. (We will make an exception for Status Update #1, if you have not been able to meet with your customer contact yet. In this case, there will probably be little to say and no point in trying to split it among all team members. But have all team members involved when it is feasible to do so.)
There are no minimum times and—except when announced in advance—no maximum times. The goal is to cover all necessary topics.
Each status update must include the following.
- Team introduction.
- Title slide at the start of the slide deck.
- Summary of what has been done and challenges encountered.
- Project Kanban board(s).
Your title slide must include the project name (so it must have a name!) and the names of all team members.
Your Kanban board (or boards) must be fully functional, with a prioritized backlog, done rules, and WIP limits.
In addition, each of the following must be included in your status update when your project has progressed far enough to make it possible.
- General project description, including deliverables.
- Description of your MVP.
- Architecture diagram(s).
- Testing plan.
- Project repository (or whatever takes its place).
- Demo/mock-up/drawing of your project.
Your testing plan does not need to be a formal document. Simply indicate how you plan to test your work and/or how you have already tested it. Reference the kinds of testing mentioned in CS 471 (see the Overview of Software Testing slides from September 25). Ad hoc testing does not count!
Concerning the demo/mock-up/drawing: demonstrate the project, if it has reached a stage where this is possible. If not, then show a mock-up or prototype, if you can. Otherwise, if you can, show a drawing or something similar indicating what your project looks like and/or how it is intended to work. If your project has no visual elements—for example, if it is a library wrapper—then you could show some sample code that uses your project.
Be clear on when your presentation ends and the time for questions and discussion begins.
Suggestions
As in CS 471:
- Do not use more slides than are needed.
- You are not there to read your slides, but to explain and elaborate on them. List key points on the slides, then discuss them in whatever detail is necessary.
- Speak up, speak clearly, make eye contact with your audience, be reasonably animated, be organized.
- Plan the logistics of your presentation in advance. Who is going to start things out? What will each group member speak about? Who runs the computer?
- Be prepared for lots of questions and discussion. When you are done with your slides, you are not done.